Jwt
Products
2- 2 CVEs
- 1 CVE
Recent CVEs
3| CVE | Vendor / Product | Sev | Risk | CVSS | EPSS | KEV | Published | Description |
|---|---|---|---|---|---|---|---|---|
| CVE-2025-45765 | Cri | 0.59 | 9.1 | 0.00 | Aug 7, 2025 | ruby-jwt v3.0.0.beta1 was discovered to contain weak encryption. NOTE: the Supplier's perspective is "keysize is not something that is enforced by this library. Currently more recent versions of OpenSSL are enforcing some key sizes and those restrictions apply to the users of this gem also." | ||
| CVE-2025-54887 | Cri | 0.52 | 9.1 | 0.00 | Aug 8, 2025 | jwe is a Ruby implementation of the RFC 7516 JSON Web Encryption (JWE) standard. In versions 1.1.0 and below, authentication tags of encrypted JWEs can be brute forced, which may result in loss of confidentiality for those JWEs and provide ways to craft arbitrary JWEs. This puts users at risk because JWEs can be modified to decrypt to an arbitrary value, decrypted by observing parsing differences and the GCM internal GHASH key can be recovered. Users are affected by this vulnerability even if they do not use an AES-GCM encryption algorithm for their JWEs. As the GHASH key may have been leaked, users must rotate the encryption keys after upgrading. This issue is fixed in version 1.1.1. | ||
| CVE-2026-45363 | hig | 0.38 | — | — | May 18, 2026 | `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:)` |
- risk 0.59cvss 9.1epss 0.00
ruby-jwt v3.0.0.beta1 was discovered to contain weak encryption. NOTE: the Supplier's perspective is "keysize is not something that is enforced by this library. Currently more recent versions of OpenSSL are enforcing some key sizes and those restrictions apply to the users of this gem also."
- risk 0.52cvss 9.1epss 0.00
jwe is a Ruby implementation of the RFC 7516 JSON Web Encryption (JWE) standard. In versions 1.1.0 and below, authentication tags of encrypted JWEs can be brute forced, which may result in loss of confidentiality for those JWEs and provide ways to craft arbitrary JWEs. This puts users at risk because JWEs can be modified to decrypt to an arbitrary value, decrypted by observing parsing differences and the GCM internal GHASH key can be recovered. Users are affected by this vulnerability even if they do not use an AES-GCM encryption algorithm for their JWEs. As the GHASH key may have been leaked, users must rotate the encryption keys after upgrading. This issue is fixed in version 1.1.1.
- risk 0.38cvss —epss —
`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:)`