What happened
CVE-2026-27962 (published 15 March 2026, CVSS 9.1) is a critical signature-verification bypass in Authlib, a widely-used Python OAuth and OpenID Connect library, affecting versions ≤ 1.6.8 and fixed in 1.6.9. When key=None is passed to Authlib's JWS deserialization, the library takes the verification key from the token's own attacker-controlled `jwk` header. An attacker can sign a JWT with their own private key, embed the matching public key in the `jwk` header, and have the server accept it as valid — impersonating any user or role. It is commonly triggered when a JWKS key-resolver callback returns None for an unknown key ID, silently falling back to the header-supplied key.
Why it matters
This is CWE-347 in its purest form: the token is trusted to supply the key that verifies it, so 'verified' means nothing. Any service that deserialized JWTs through Authlib with a resolver that could return None for unknown or rotated key IDs was one crafted token away from full authentication bypass — no credentials and no server keys required.
Patch to 1.6.9, but the real lesson is a design invariant: the verification key MUST come from your application's trust store, never from the token. The Staff move is to grep the auth path for anything that resolves keys from token headers (jwk/jku/x5u/kid fallbacks), pin the accepted algorithms, and add a test that a token carrying its own key is rejected. Then ask where else a 'not found' key lookup fails open instead of closed.
Why is trusting a JWT's own `jwk`/`kid` header to select the verification key dangerous, and how would you design JWT validation so a forged token can't pass?
Probes signature verification, key management, and fail-closed design.