Executive Summary

[{'type': 'paragraph', 'content': "CVE-2026-27962 is a critical vulnerability in the Authlib Python library's JSON Web Signature (JWS) implementation. It arises from a flaw where, if no cryptographic key is provided (key=None) during JWT deserialization, the library incorrectly uses the public key embedded in the JWT's header (the 'jwk' field) for signature verification."}, {'type': 'paragraph', 'content': 'This allows an attacker to create their own key pair, sign a JWT with arbitrary claims (such as elevated privileges), embed the corresponding public key in the token header, and have the server accept this forged token as valid without raising any verification errors.'}, {'type': 'paragraph', 'content': 'The root cause is that the library violates the security principle that verification keys must come from a trusted application context, not from untrusted token headers. This fallback behavior was removed in version 1.6.9 to prevent this attack.'}] [1]

Useful 0 Not Useful 0

Impact Analysis

This vulnerability allows unauthenticated attackers to forge arbitrary JWT tokens that pass signature verification, effectively bypassing authentication and authorization controls.

An attacker can impersonate any user or assume any privilege encoded in JWT claims, such as administrative roles, without possessing legitimate credentials.

Because the forged tokens are accepted as cryptographically valid, this can lead to unauthorized access to sensitive data, privilege escalation, and compromise of application security.

Useful 0 Not Useful 0

Compliance Impact

I don't know

Useful 0 Not Useful 0

Detection Guidance

[{'type': 'paragraph', 'content': 'This vulnerability involves forged JWT tokens that pass signature verification due to the library accepting attacker-controlled JWK headers when no key is provided. Detection involves identifying JWT tokens with embedded "jwk" headers that are not expected or authorized by your application.'}, {'type': 'paragraph', 'content': 'You can inspect JWT tokens used in your system for the presence of a "jwk" field in the header. For example, decode JWT tokens and check their headers for the "jwk" parameter.'}, {'type': 'list_item', 'content': 'Use a command-line tool like `jq` to decode JWT headers from logs or intercepted tokens: `echo \'<JWT_TOKEN>\' | cut -d \'.\' -f1 | base64 -d | jq` and check for a "jwk" field.'}, {'type': 'list_item', 'content': 'Monitor logs or network traffic for JWT tokens containing unexpected or suspicious "jwk" headers.'}, {'type': 'list_item', 'content': "Check your application code or logs for calls to Authlib's JWS deserialization functions (`deserialize_compact()`, `deserialize_json()`, or `deserialize()`) where the key parameter might be `None`."}, {'type': 'paragraph', 'content': 'Since the vulnerability arises when the key parameter is `None` and the library falls back to the embedded "jwk" header, auditing your code for such usage patterns can help detect potential exploitation.'}] [1]

Useful 0 Not Useful 0

Mitigation Strategies

[{'type': 'paragraph', 'content': 'The primary mitigation is to upgrade the Authlib library to version 1.6.9 or later, where the vulnerable fallback logic that uses the "jwk" header when the key is `None` has been removed.'}, {'type': 'paragraph', 'content': 'If upgrading immediately is not possible, ensure that your application never calls JWS deserialization functions with a `None` key parameter. Instead, always provide a trusted cryptographic key from your application context.'}, {'type': 'list_item', 'content': 'Remove or patch any code that allows the library to fallback to the embedded "jwk" header for key verification.'}, {'type': 'list_item', 'content': 'Explicitly raise an error or handle cases where no valid key is resolved, preventing silent acceptance of attacker-controlled keys.'}, {'type': 'paragraph', 'content': 'Review your JWT verification logic to ensure it complies with RFC 7515 recommendations by not trusting keys embedded in JWT headers.'}] [1, 2, 3]

Useful 0 Not Useful 0