GHSA-h395-gr6q-cpjc: jsonwebtoken has Type Confusion that leads to potential authorization bypass
Summary:It has been discovered that there is a Type Confusion vulnerability in jsonwebtoken, specifically, in its claim validation logic.When a standard claim (such as nbf or exp) is provided with an incorrect JSON type (Like a String instead of a Number), the library’s internal parsing mechanism marks the claim as “FailedToParse”. Crucially, the validation logic treats this “FailedToParse” state identically to “NotPresent”.This means that if a check is enabled (like: validate_nbf = true), but the claim is not explicitly marked as required in required_spec_claims, the library will skip the validation check entirely for the malformed claim, treating it as if it were not there. This allows attackers to bypass critical time-based security restrictions (like “Not Before” checks) and commit potential authentication and authorization bypasses.Details:The vulnerability stems from the interaction between the TryParse enum and the validate function in [src/validation.rs](https://github.com/Keats/jsonwebtoken/blob/master/src/validation.rs).The TryParse Enum: The library uses a custom TryParse enum to handle claim deserialization:If a user sends {“nbf”: “99999999999”} (legacy/string format), serde fails to parse it as u64, and it results in TryParse::FailedToParse.The Validation Logic Flaw (src/validation.rs): In Validation::validate, the code checks for exp and nbf
like this:This matches! macro explicitly looks for TryParse::Parsed(nbf).• If claims.nbf is FailedToParse, the match returns false.
 • The if block is skipped.
 • No error is returned.The “Required Claims” Gap: The only fallback mechanism is the “Required Claims” check:If “nbf” IS in required_spec_claims, FailedToParse will fail the matches!(..., Parsed(_)) check, causing the present to be false, and correctly returning an error.However, widely accepted usage patterns often enable validation flags (validate_nbf = true) without adding the claim to the required list, assuming that enabling validation implicitly requires the claim’s validity if it appears in the token. jsonwebtoken seems to violate this assumption.Environment:• Version: jsonwebtoken 10.2.0
 • Rust Version: rustc 1.90.0
 • Cargo Version: cargo 1.90.0
 • OS: MacOS Tahoe 26.2POC:For demonstrating, Here is this simple rust code that demonstrates the bypass. It attempts to validate a token with a string nbf claiming to be valid only in the far future.create a new project:add required dependencies:replace the code in src/main.rs with this:run cargo runexpected behaviour:Token was accepted despite malformed far-future 'nbf'!
Impact:If an application uses jsonwebtoken nbf (Not Before) to schedule access for the future (like “Access granted starting tomorrow”).By sending nbf as a string, an attacker can bypass this restriction and access the resource immediately.and for the exp claim (this is unlikely but still adding), If a developer sets validate_exp = true but manually handles claim presence (removing exp from required_spec_claims), an attacker can send a string exp (e.g., “never”) and bypass expiration checks entirely. The token becomes valid forever.
CVSS v4.0: 5.5