CVE-2026-45363
Improper Authentication vulnerability in jwt (RubyGems)
What is CVE-2026-45363 About?
This vulnerability allows an attacker to forge JWT tokens by exploiting the `JWT.decode` method when an empty verification key (`""`) is used with HMAC algorithms. This is due to `OpenSSL::HMAC.digest` returning a valid digest for an empty key, bypassing signature verification and enabling token impersonation. The ease of exploitation is moderate, as it relies on specific key handling configurations in the application.
Affected Software
Technical Details
The vulnerability lies in the interaction between the JWT.decode method and OpenSSL::HMAC.digest when an empty string ("") is used as the verification key for HMAC algorithms (HS256/HS384/HS512). Specifically, OpenSSL::HMAC.digest('SHA256', '', payload) (or similar for other HMAC functions) returns a valid digest even with an empty key, which is then successfully compared against an attacker-forged signature. The JWT.decode method calls JWA::Hmac.verify(verification_key: "", ...), which subsequently invokes the OpenSSL::HMAC.digest function. This behavior is compounded because JWT::Decode#find_key does not reject empty string keys returned by keyfinder blocks or key_finder: arguments, and JWT::JWA::Hmac silently coerces nil to "" before signing if not explicitly handled. Thus, if an application's key management (e.g., redis.get("kid:#{kid}").to_s, ORM string columns with default: '', ENV['SECRET'] || '') can result in an empty string being used as the HMAC key, an attacker can craft a valid token with a legitimate signature using the empty key, effectively bypassing authentication.
What is the Impact of CVE-2026-45363?
Successful exploitation may allow attackers to impersonate legitimate users by forging JWT tokens, potentially leading to unauthorized access and privilege escalation.
What is the Exploitability of CVE-2026-45363?
Exploitation of this vulnerability requires the application to inadvertently use an empty string ("") as the verification key for HMAC-signed JWTs. The complexity is moderate, as it depends on application-specific key management logic that could lead to an empty key. No authentication is strictly required to craft the malicious token, but the token would then be used to bypass authentication or gain unauthorized access within the application. No special privileges are needed to forge the token, and the attack is typically remote, carried out by submitting the forged token. Critical conditions include the application relying on JWT.decode with an empty key and not enforcing HMAC key length (as enforce_hmac_key_length defaults to false). The vulnerability is compounded by OpenSSL ≥ 3.5 no longer raising an error for empty-key HMAC.digest calls. This increases the likelihood if the application's key retrieval logic can yield empty or nil values.
What are the Known Public Exploits?
| PoC Author | Link | Commentary |
|---|---|---|
| No known exploits | ||
What are the Available Fixes for CVE-2026-45363?
Available Upgrade Options
- jwt
- <3.2.0 → Upgrade to 3.2.0
Struggling with dependency upgrades?
See how Resolved Security's drop-in replacements make it simple.
Book a demoAdditional Resources
What are Similar Vulnerabilities to CVE-2026-45363?
Similar Vulnerabilities: CVE-2023-45133 , CVE-2022-3868 , CVE-2022-2977 , CVE-2021-3801 , CVE-2021-23638
