CVE-2026-27962

What it actually does

Authlib’s JWS deserialization, when invoked without an application-supplied verification key (key=None), trusts the attacker-controlled jwk header inside the JWT and uses that embedded public key to verify the signature. Signature verification therefore no longer proves possession of a server-trusted key: any self-signed JWT whose public key is carried in the header is treated as cryptographically valid, fully bypassing authentication and authorization that depend on JWS/JWT integrity.

Why it matters to the business

Any product that uses vulnerable Authlib to gate logins, APIs, or OAuth/OpenID Connect flows can have those controls silently defeated, enabling account takeover, unauthorized API access, and data disclosure or tampering. Impact is highest for internet-facing identity and API services. The issue is unauthenticated and network-reachable (CVSS 9.1) and should be treated as high priority even though it is not on CISA KEV, is not tied to ransomware, has no reported in-the-wild exploit maturity, and currently has a low EPSS (~0.5%, slightly declining). Upgrade remaining unpatched dependents promptly.

How an attack unfolds

An unauthenticated remote attacker generates their own key pair, builds a JWT with chosen identity and privilege claims, signs it with the private key, and places the matching public key in the JWT jwk header. If the target calls Authlib JWS deserialize/verify without passing a trusted key, the library extracts the header-embedded key and confirms the signature against it. The forged token is accepted as valid, so the attacker impersonates users or assumes roles without credentials. No named threat actors or KEV campaigns are associated with this CVE at present.

How to fix it

Upgrade the authlib package to 1.6.9 or later in all applications, services, and lockfiles (pip, Poetry, pip-tools, uv, conda). After upgrading, require every JWS/JWT verification call to pass an application-controlled key or JWKS; never rely on keys taken from the token header. Search code and dependencies for JWS deserialize/decode/verify calls that omit a key or pass key=None, and for any acceptance of the jwk header parameter. Rotate signing keys and invalidate sessions or refresh tokens issued while vulnerable versions were in production if token forgery cannot be ruled out. Pin and monitor authlib so it cannot regress below 1.6.9.

How to confirm the fix worked

Confirm installed authlib is 1.6.9 or newer (pip show authlib, poetry show authlib, or lockfile review) in every runtime image and virtualenv. Statically search for JWS verification without an explicit key and for use of the jwk header. In a non-production check, verify that tokens whose only verification material is a header-embedded jwk are rejected after the upgrade. Regression-test legitimate JWKS/key-based verification still succeeds. Inventory transitive dependents of authlib across services.

Typical attack path

1. Identify an application that verifies JWTs with Authlib JWS and does not pass an explicit trusted key (key=None or equivalent).
2. Create an attacker-controlled signing key pair.
3. Produce a JWT with attacker-chosen claims, signed with that private key and carrying the corresponding public key in the jwk header.
4. Submit the token to an authentication, SSO, or API endpoint that deserializes it with Authlib.
5. Receive a session, token, or API response granted on the basis of the forged claims and act with the corresponding privileges.

How to detect it

This flaw leaves no unique malware implant; evidence is in authentication logs and captured tokens. Hunt historical HTTP access, API gateway, IdP, and application auth logs for Bearer JWTs whose decoded protected header contains a jwk object, especially where verification succeeded. Compare the key in that header (or the effective kid/thumbprint) against the service’s trusted JWKS—a match to an unknown key on a successful login or API call is a strong signal. Review application debug or exception logs around Authlib/JWS verification for acceptance of header-supplied keys. Check whether new users, privilege changes, or high-value API calls clustered around tokens that were not signed by your keys. Package and image inventories showing authlib < 1.6.9 indicate exposure, not necessarily compromise. There are no named APT mappings; use these artifacts rather than actor-specific IOCs.

• Decoded JWT protected header JSON containing a "jwk" member
• HTTP Authorization: Bearer tokens whose first (header) segment base64url-decodes to JSON with "jwk"
• Successful auth/API events where the verifying key thumbprint is absent from the application JWKS
• authlib distribution/version evidence: authlib<1.6.9 in site-packages, METADATA, or lockfiles (exposure indicator)
• Python import/runtime of authlib.jose JWS deserialize/verify without an explicit key argument (code-level exposure)

What your security team should do

• Patch authlib to 1.6.9+ everywhere it is used, treating internet-facing auth and API services first.
• Ban key=None / missing-key JWS verification in code review and SAST; require an explicit trusted key or JWKS.
• Inventory all Python services for authlib < 1.6.9 via SCA and lockfiles, including transitive use.
• If a vulnerable verifier was exposed, rotate JWT signing keys and revoke or re-issue sessions and refresh tokens.
• Add detection for JWTs that carry a jwk header on authentication paths and alert on successful auths not matching the trusted JWKS.
• Keep authlib pinned at or above 1.6.9 in base images and dependency policy.