## Critical Vulnerability Information - **CVE ID**: CVE-2026-25537 - **Severity**: Medium ### Vulnerability Overview - **Type**: Type confusion vulnerability - **Location**: Declaration validation logic in the jsonwebtoken library - **Affected Versions**: < 10.3.0 - **Fixed Version**: 10.3.0 #### Vulnerability Description - **Issue**: When standard claims (e.g., `nbf` or `exp`) are provided with incorrect JSON types (e.g., string instead of number), the library's internal parsing mechanism marks them as "FailedToParse". The validation logic treats the "FailedToParse" state equivalently to "NotPresent". - **Impact**: Even if validation checks are enabled (e.g., `validate_nbf = true`), if the claim is not explicitly marked as required in `required_spec_claims`, the library completely skips the validation check, treating it as absent. This allows attackers to bypass time-based security restrictions (e.g., "Not Before" checks) and potentially bypass authentication and authorization. ### Detailed Information - **TryParse Enum**: The library uses a custom `TryParse` enum to handle claim deserialization. When a user sends `nbf` as a string, `serde` cannot parse it into `u64`, resulting in `TryParse::FailedToParse`. - **Validation Logic Flaw**: During validation, the code checks `exp` and `nbf`. If `nbf` is `FailedToParse`, the match fails, the `if` block is skipped, and no error is returned. - **Gap in Required Claims**: The only fallback mechanism is the "required claims" check. However, common usage patterns typically enable validation flags (e.g., `validate_nbf = true`) without adding claims to the required list, assuming that if a claim is present in the token, its validity is implicitly required. This assumption is violated by the vulnerability. ### Environment - Version: jsonwebtoken 10.2.0 - Rust Version: rustc 1.90.0 - Cargo Version: cargo 1.90.0 - Operating System: MacOS Tahoe 26.2 ### POC (Proof of Concept) - The POC demonstrates how to bypass validation by sending `nbf` as a string, causing a future-dated token to be considered valid. ### Impact - If an application uses jsonwebtoken’s `nbf` (not yet) to schedule future access rights (e.g., "access granted tomorrow"), an attacker can bypass this restriction by sending `nbf` as a string and immediately gain access to resources.