Authlib’s JWS verification accepts tokens that declare unknown critical header parameters (crit), violating RFC 7515 “must‑understand” semantics. An attacker can craft a signed token with a critical header (for example, bork or cnf) that strict verifiers reject but Authlib accepts. In mixed‑language fleets, this enables split‑brain verification and can lead to policy bypass, replay, or privilege escalation.
authlib.jose.JsonWebSignature.deserialize_compact(...)critRFC 7515 (JWS) §4.1.11 defines crit as a “must‑understand” list: recipients MUST understand and enforce every header parameter listed in crit, otherwise they MUST reject the token. Security‑sensitive semantics such as token binding (e.g., cnf from RFC 7800) are often conveyed via crit.
Observed behavior with Authlib 1.6.3:
crit: ["cnf"] and a cnf object, or crit: ["bork"] with an unknown parameter, Authlib verifies the signature and returns the payload without rejecting the token or enforcing semantics of the critical parameter.jose v5 both reject such tokens by default when crit lists unknown names.Impact in heterogeneous fleets:
crit carries binding or policy information.This repository provides a multi‑runtime PoC demonstrating the issue across Python (Authlib), Node (jose v5), and Java (Nimbus).
Enter the directory...
1.6.4Exploitability
AV:NAC:LPR:NUI:NScope
S:UImpact
C:NI:HA:N7.5/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N