CVE-2026-27962: Authlib JWS JWK Header Injection Signature Verification Bypass
CVE-2026-27962 affects the Authlib Python library before version 1.6.9. When key=None is passed to JWS deserialization functions, the library can use a key embedded in the attacker-controlled jwk header, which may let forged JWT tokens pass signature verification. The GitHub CNA rates it critical with a CVSS base score of 9.1, and the record does not list it in CISA KEV.
Overview
Authlib is a Python library for building OAuth and OpenID Connect servers. According to the record, CVE-2026-27962 is a JWK Header Injection issue in its JWS implementation: when key=None is passed to a JWS deserialization function, the library can take the key from the token's own jwk header. The GitHub CNA describes the result as a signature verification bypass, mapped to CWE-347.
Impact
- The record describes forged JWT tokens passing signature verification, which could bypass authentication and authorization.
- The GitHub CNA scores the issue critical with a CVSS base score of 9.1, reflecting network reachability, no required privileges and no required user interaction.
- The SSVC fields in the record show total technical impact and automatable status set to yes.
Affected products and versions
- Product: Authlib (Python).
- Affected: versions before 1.6.9.
- Fixed: 1.6.9, according to the record.
The record repeats the affected range in two equivalent entries. This analysis uses only the 1.6.9 boundary.
Exploitation status
The record does not list this CVE in the CISA KEV catalog, so active exploitation is not confirmed here. The SSVC exploitation value in the record is poc, meaning proof-of-concept activity is a planning consideration, but this is not evidence of exploitation in the wild. No confirmed exploitation appears in the sources consulted.
Remediation and mitigation
- Upgrade Authlib to version 1.6.9 or later, as indicated by the release and the vendor advisory.
- Review application code for calls to JWS deserialization functions that pass key=None, and make sure verification keys come from trusted, server-controlled configuration rather than from token headers.
- Consult the vendor advisory for recommended interim mitigations while the upgrade is scheduled.
- If your product uses Authlib indirectly, check your dependency tree and downstream vendor advisories.
Detection guidance
- Review authentication logs for tokens accepted from unexpected issuers or keys, and for token activity that does not match known signing keys.
- Maintain an inventory of applications that use Authlib and their library versions.
- Monitor for unusual privilege use after authentication events, since a forged token would appear valid to the server.
Limitations of the available information
- The record does not describe the vulnerable code paths beyond its summary, and it does not include proof-of-concept details.
- The GitHub advisory link is tagged as an exploit reference in the record, but its content was not reviewed for this analysis.
- Red Hat errata and VEX links appear in the record but were not reviewed here.
- Whether a specific deployment is affected depends on whether it calls JWS deserialization with key=None, which the record cannot confirm.
Frequently asked questions
Is this Authlib vulnerability being actively exploited?
The record does not list CVE-2026-27962 in the CISA KEV catalog, and no confirmed exploitation appears in the sources consulted. The SSVC exploitation value is poc, which indicates proof-of-concept status and is not the same as active exploitation.
What should I do if I use Authlib?
Upgrade Authlib to version 1.6.9 or later. Also review any use of JWS deserialization with key=None so that verification keys come only from trusted server-side configuration.
This analysis was drafted with AI assistance from verified source data and automatically checked against it.