Authlib CVE-2026-114616

Exploitation requires the deploying Authlib-based verifier to resolve its symmetric (oct) HMAC verification key to an empty string or empty bytes at runtime - for example os.environ.get('JWT_SECRET', ''), a config/database value whose default is '', or a key-resolver returning '' on a lookup miss - and the token must use an HMAC algorithm (HS256, HS384 or HS512). Under those conditions a remote unauthenticated attacker (PR:N) can forge valid tokens, because OctKey.import_key/validate_raw_key in versions <1.9.1 perform only a type check and never reject zero-length material, so hmac.new(b'', ...) yields a publicly reproducible digest. The key LIMITING factor (reflected in AC:H) is that this is NOT a default-configuration flaw: applications that always supply a non-empty secret are not exploitable, and asymmetric (RS/ES) verification paths are unaffected.

This is a genuine authentication-bypass flaw but one whose real-world risk is strongly gated by a deployment precondition rather than being universally exploitable. The supplied CVSS vector (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N) correctly captures this: network reach, no privileges and no user interaction, but AC:H because exploitation requires the victim application to verify tokens with a zero-length HMAC secret. Note a data conflict: the input header lists CVSS 7.4 while the GHSA advisory and the provided vector compute to 8.1 - the vector string, not the 7.4 base figure, governs this analysis. No EPSS score and no KEV listing are present in the input, and the vuln.today decision label is 'this_week' (not act_now/emergency), so there is no signal of active or widespread exploitation; this is a serious but not emergency-grade item. A public PoC reference exists in the GHSA advisory and the fix-commit test, but it is a conceptual/prose reproduction, not verified weaponized exploit code. The decisive variable is configuration: applications that always load a real secret are not affected, so defenders should prioritize auditing their Authlib secret-resolution paths rather than treating every Authlib deployment as exposed.

An OAuth 2.0 resource server or OIDC relying party built on Authlib resolves its HMAC verification secret from a source that can be empty at runtime - e.g. os.environ.get('JWT_SECRET', ''), a config/DB column defaulting to '', or a key resolver that returns '' on a miss. A remote unauthenticated attacker crafts a JWT with arbitrary claims (elevated scopes or another user's subject), computes the deterministic HS256/384/512 signature using an empty key, and Authlib accepts the forged token as authentic. The GHSA advisory documents a prose reproduction and the fix commit adds a forging test, but no weaponized exploit is published.