ruby-jwt CVE-2026-45363

Exploitation requires the target application to be running ruby-jwt < 3.2.0 with HS256/HS384/HS512 verification AND to supply an empty string ('') or nil as the verification key - either as the positional argument to JWT.decode, as the return value of a keyfinder block, or via the key_finder: argument to JWT::EncodedToken#verify_signature!. Concretely vulnerable patterns named in the advisory: redis.get("kid:#{kid}").to_s on a cache miss, ORM string columns declared with default: '', ENV['SECRET'] || '', Hash.new('') lookups for unknown kids, and [primary, fallback] key arrays where fallback may be nil. Limiting factors: applications that pass a non-empty static key, whose keyfinder returns literal nil (rejected by find_key), or that have enabled the non-default enforce_hmac_key_length option are NOT exploitable. The CVSS AC:H reflects that the attacker must identify or guess that the target falls into one of the unsafe key-resolution patterns; PR:N confirms no prior authentication is needed once that condition holds.

CVSS 7.4 (AV:N/AC:H/PR:N/UI:N/C:H/I:H/A:N) reflects high confidentiality and integrity impact against unauthenticated network attackers, with AC:H acknowledging that exploitability depends on a specific application-side condition (the verification key resolving to '' or nil). No EPSS, KEV, or POC data was provided, so per policy this is treated as no public exploit identified at time of analysis - not a contradiction of the high CVSS, but a signal that mass exploitation is not yet observed. Real-world risk is bimodal: applications passing a non-empty static secret are unaffected, but those using Redis-backed kid lookups (redis.get("kid:#{kid}").to_s), ORM columns defaulting to '', ENV['SECRET'] || '', Hash.new(''), or [primary, fallback]-with-nil patterns are trivially bypassable. The enforce_hmac_key_length option would have blocked this but ships disabled by default, so most deployments are exposed until upgraded. Defenders should treat this as a high-priority library upgrade for any Ruby service handling JWT-based auth, even without active-exploitation signals.

An attacker crafts a JWT with header {"alg":"HS256"}, an arbitrary payload (e.g. {"user_id":1,"role":"admin"}), and a signature computed via HMAC-SHA256 using an empty key. They submit the token to a vulnerable Rails API whose authentication middleware looks up the signing key from Redis by kid - redis.get("kid:#{kid}").to_s returns '' on a cache miss - and ruby-jwt < 3.2.0 verifies the forged token, granting admin access without credentials. No public PoC was provided, but the advisory's two-line reproducer makes weaponization trivial for any affected deployment pattern.