CVE-2026-25537: 
Rust vulnerability analysis and mitigation

CVE-2026-25537 is a Type Confusion vulnerability in the jsonwebtoken Rust library (crate by Keats) that allows attackers to bypass critical time-based JWT claim validation, enabling authentication and authorization bypasses. The flaw affects all versions prior to 10.3.0 of the jsonwebtoken crate for Rust. It was published on February 4, 2026, with a patch released in version 10.3.0 on January 27, 2026. The vulnerability carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, Feedly).

The root cause is classified as CWE-843 (Access of Resource Using Incompatible Type / Type Confusion). The library uses a custom TryParse enum with three states — Parsed(T), FailedToParse, and NotPresent — to handle JWT claim deserialization. When a standard numeric claim such as nbf or exp is provided as a JSON string (e.g., "nbf": "99999999999") instead of a number, serde fails to deserialize it, resulting in TryParse::FailedToParse. The validation logic in src/validation.rs uses matches!(claims.nbf, TryParse::Parsed(nbf) if ...), which silently skips the check when the state is FailedToParse — treating it identically to NotPresent. This bypass is only triggered when validate_nbf = true (or validate_exp = true) is set but the claim is not explicitly listed in required_spec_claims, a common configuration pattern. The fix in version 10.3.0 adds explicit rejection of FailedToParse states when the corresponding validation flag is enabled, returning a new InvalidClaimFormat error (GitHub Commit, GitHub Advisory).

Successful exploitation allows an attacker who can craft or forge a JWT token to bypass nbf (Not Before) restrictions — for example, gaining access to a resource before its scheduled availability window — or bypass exp (expiration) checks, making a token valid indefinitely. The attack requires no privileges and no user interaction, is network-accessible, and has low complexity. The primary impact is on integrity (unauthorized access/authorization bypass); there is no direct confidentiality or availability impact, though downstream consequences of unauthorized access can be severe depending on the application (GitHub Advisory, Feedly).

1. Craft a malformed JWT payload: Create a JWT claims structure where nbf (or exp) is set as a JSON string instead of a number — e.g., {"sub": "attacker", "nbf": "99999999999", "exp": 10000000000}. The string value represents a far-future timestamp to bypass the Not Before check.
2. Encode the token: Sign the token using the target application's expected algorithm (e.g., HS256) and a known or guessed secret key: encode(&Header::default(), &claims, &EncodingKey::from_secret(key)).
3. Submit the token: Send the crafted JWT to the target application's authenticated endpoint via an HTTP request with the token in the Authorization: Bearer <token> header.
4. Bypass validation: The server-side jsonwebtoken library (version < 10.3.0) attempts to parse nbf as a u64, fails, sets it to TryParse::FailedToParse, and the matches! macro in the validation logic skips the nbf check entirely — accepting the token as valid despite the malformed far-future nbf.
5. Achieve unauthorized access: The application grants access as if the token were legitimately valid, bypassing time-based access controls (GitHub Advisory, GitHub Commit).

• Network: HTTP requests to authenticated endpoints bearing JWT tokens where the decoded payload contains nbf or exp fields with string values (e.g., "nbf": "99999999999") rather than numeric values.
• Logs: Application logs showing successful JWT validation for tokens with nbf timestamps far in the future or exp values that are non-numeric strings; absence of InvalidClaimFormat errors in applications running jsonwebtoken < 10.3.0 despite malformed tokens being submitted.
• File System: Presence of jsonwebtoken crate versions prior to 10.3.0 in Cargo.lock or Cargo.toml files within deployed Rust applications.
• Process/Application Behavior: Unexpected successful authentication or access to time-restricted resources by users or services that should not yet have access based on nbf policy (GitHub Advisory).

Upgrade the jsonwebtoken Rust crate to version 10.3.0 or later, which explicitly rejects tokens where exp or nbf claims fail to parse when the corresponding validation flag is enabled. As an interim workaround for applications that cannot immediately upgrade, explicitly add "nbf" and "exp" to required_spec_claims in the Validation configuration — this causes FailedToParse to trigger a MissingRequiredClaim error, preventing the bypass. Additionally, audit JWT validation configurations across all services using this library to ensure claims are properly declared as required where validation is enabled (GitHub Advisory, GitHub Commit).

The vulnerability was reported by security researcher Kr1shna4garwal and published by the maintainer (Keats) via GitHub Security Advisories on February 3, 2026. Fedora Linux issued security updates for multiple Rust packages depending on jsonwebtoken, with advisories tracked across Fedora 42 and 43. Tenable released multiple Nessus detection plugins (IDs 298172, 298322, 298323, 298446, 298573) to identify vulnerable installations. Coverage appeared across vulnerability aggregators and Linux security news outlets shortly after disclosure (GitHub Advisory, Tenable).