Authlib CVE-2026-114615

Exploitation requires two non-default deployment properties, neither attacker-controlled at request time: (1) the relying party uses Authlib's documented module-level jwt object (from authlib.jose import jwt), whose JsonWebToken.decode exposes no 'algorithms' parameter and whose registry includes both HS* and RS*/ES*/PS*/EdDSA, so symmetric and asymmetric schemes are mixed; and (2) the verification key is passed as PEM or X.509 certificate text whose bytes do NOT begin at offset 0 with '-----BEGIN ' - i.e. a single leading newline (as produced by a triple-quoted Python literal), a leading space, four-space indentation (indented YAML/JSON/TOML), a UTF-8 BOM, or a leading comment line. The attacker needs only the issuer's public key (public by definition) and no authentication or user interaction. Limiting factors that reduce real-world exposure: a canonical PEM starting exactly at offset 0 is NOT vulnerable (the guard still fires); pinning the algorithm via JsonWebToken(['RS256']) is confirmed by the PoC's controls to block the forgery; and only the deprecated authlib.jose path is affected (joserfc, the recommended successor, types keys with an explicit kty and raises InvalidKeyTypeError, so it is unaffected).

This is a genuine high-severity authentication-bypass (algorithm/key confusion) in Authlib's deprecated-but-still-shipped authlib.jose module, rated CVSS 7.4. The supplied vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N is internally consistent with the description: AV:N (token submitted remotely), PR:N and UI:N (the attacker needs only the issuer's public key, which is public by definition via JWKS/IdP metadata, and no victim interaction), and C:H/I:H (forging arbitrary identity and authorization claims breaks both confidentiality and integrity). AC:H correctly reflects that success is gated on two deployment properties the attacker does not control. No EPSS score and no CISA KEV entry are provided, so there is no evidence of active exploitation - exploitation status is 'no public exploit identified' in KEV terms, but this must not be read as 'no exploit': the GHSA advisory contains a detailed end-to-end proof-of-concept (Flask API, forged HS256 token minted from the public key) reproduced on 1.8.0 and origin/main. The vuln.today decision label is 'this_week' (prioritize, not emergency), which aligns with a serious bug that nonetheless requires a specific non-default configuration. The signals are therefore consistent rather than conflicting: high technical impact and a documented PoC on a package with ~103M monthly PyPI downloads push priority up, while the dependence on a mixed HS/RS algorithm registry plus a leading-byte-prefixed PEM, the absence of KEV/EPSS, and the fact that authlib.jose is deprecated (the vendor recommends joserfc, which is not affected) temper real-world blast radius. Net: a real patch-this-week priority for anyone using authlib.jose's module-level jwt object with PEM/certificate verification keys, not merely a high-CVSS paper risk.

An unauthenticated attacker retrieves the issuer's RSA or EC public key - publicly available at /.well-known/jwks.json or in IdP metadata - and uses those exact PEM bytes as an HMAC secret to mint an HS256 JWT carrying arbitrary subject and role claims (e.g. sub=attacker, role=admin). Against a relying party that calls Authlib's documented module-level jwt.decode() with a verification key stored as PEM/certificate text that has any leading byte (newline, space, indentation, BOM, or comment line), the forged token verifies as authentic and grants admin access. A full end-to-end PoC demonstrating exactly this (yielding HTTP 200 and admin secrets) is published in the GHSA advisory.