PT-2026-41777 · Rubygems · Jwt

Published

2026-05-18

·

Updated

2026-05-18

·

CVE-2026-45363

CVSS v3.1

7.4

High

VectorAV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
JWT.decode(token, '', true, algorithm: 'HS256') accepts an attacker-forged token. OpenSSL::HMAC.digest('SHA256', '', payload) returns a valid digest under an empty key, and no raise InvalidKeyError if key.empty? precondition exists in the HMAC algorithm.
JWT.decode(token, "", true, algorithm: 'HS256')
 -> JWA::Hmac.verify(verification key: "", ...)
 -> OpenSSL::HMAC.digest('SHA256', "", signing input) == signature
The same path is reached when a keyfinder block or key finder: argument returns "", nil, or an array containing nil for an unknown key. JWT::Decode#find key only rejects literal nil and empty arrays, and JWT::JWA::Hmac silently coerces nil to "" (signing key ||= '') before signing.
JWT.decode(token, nil, true, algorithms: ['HS256']) { | h| "" }
 -> find key returns ""        # "" && !Array("").empty? == true
 -> JWA::Hmac.verify(verification key: "", ...)
 -> verifies
Common application patterns that produce the unsafe value: redis.get("kid:#{kid}").to s, ORM string columns with default: '', ENV['SECRET'] || '', Hash.new('') lookups, [primary, fallback] where fallback may be nil. Applications passing a non-empty static key:, or whose keyfinder returns nil / raises on miss, are not affected.
The existing enforce hmac key length option would block this but defaults to false. On OpenSSL ≥ 3.5 the empty-key HMAC.digest call no longer raises, so the OpenSSL-3.0 rescue in JWA::Hmac#sign does not fire.
Affects HS256/HS384/HS512 via both JWT.decode (positional key and block keyfinder) and JWT::EncodedToken#verify signature!(key finder:)

Fix

Inadequate Encryption Strength

Improper Authentication

Weakness Enumeration

CWE-326CWE-1391CWE-287

Related Identifiers

CVE-2026-45363
GHSA-C32J-VQHX-RX3X

Affected Products

Jwt