CVE-2026-25537: jsonwebtoken Rust Auth Bypass Vulnerability

CVE-2026-25537 Overview

CVE-2026-25537 is a Type Confusion vulnerability affecting the jsonwebtoken library, a widely-used JWT (JSON Web Token) implementation for the Rust programming language. The vulnerability exists in the claim validation logic where malformed claims with incorrect JSON types can bypass critical security checks.

When a standard claim such as nbf (Not Before) or exp (Expiration) is provided with an incorrect JSON type (for example, a String instead of a Number), the library's internal parsing mechanism marks the claim as "FailedToParse". The validation logic then treats this "FailedToParse" state identically to "NotPresent", allowing attackers to craft tokens that bypass time-based security restrictions.

Critical Impact

Attackers can bypass authentication and authorization mechanisms by crafting JWT tokens with malformed claims that evade time-based security restrictions like "Not Before" checks.

Affected Products

• jsonwebtoken (Rust library) versions prior to 10.3.0

Discovery Timeline

• 2026-02-04 - CVE-2026-25537 published to NVD
• 2026-02-05 - Last updated in NVD database

Technical Details for CVE-2026-25537

Vulnerability Analysis

This Type Confusion vulnerability (CWE-843) allows attackers to circumvent JWT claim validation by exploiting a flaw in how the library handles type mismatches during claim parsing. The core issue stems from the library conflating two distinct states: a claim that was never included in the token versus a claim that exists but could not be properly parsed due to type mismatch.

When validation is configured with validate_nbf = true but the nbf claim is not explicitly added to required_spec_claims, the library permits tokens where the nbf claim is either absent or unparseable. An attacker can exploit this by providing "nbf": "malicious_string" instead of the expected numeric timestamp, causing the validation to be skipped entirely.

Root Cause

The root cause lies in the validation logic treating "FailedToParse" claims identically to "NotPresent" claims. This design flaw means that enabling a validation check (like validate_nbf = true) does not guarantee the check will execute if the claim can be malformed in a way that causes parsing failure. The library should have treated parsing failures as validation errors rather than optional absent claims.

Attack Vector

The attack vector is network-based, requiring no authentication or user interaction. An attacker crafts a JWT token with standard claims (such as nbf, exp, or iat) using incorrect JSON types. For example:

{
  "sub": "attacker",
  "nbf": "invalid_string_instead_of_number",
  "exp": "also_invalid"
}

When this malformed token is processed by an application using vulnerable versions of jsonwebtoken, the time-based validation checks are bypassed, potentially allowing:

• Use of tokens before their intended activation time
• Use of tokens after their intended expiration
• Authentication bypass in systems relying on JWT time claims

The security patch introduces a new error type InvalidClaimFormat to properly distinguish parsing failures from absent claims:

    // Validation errors
    /// When a claim required by the validation is not present
    MissingRequiredClaim(String),
+    /// When a claim has an invalid format (eg string instead of integer)
+    InvalidClaimFormat(String),
    /// When a token's `exp` claim indicates that it has expired
    ExpiredSignature,
    /// When a token's `iss` claim does not match the expected issuer

Source: GitHub Commit Update

Detection Methods for CVE-2026-25537

Indicators of Compromise

• JWT tokens containing claims with unexpected data types (strings instead of numbers for nbf, exp, iat)
• Authentication logs showing successful token validation for tokens that should have been rejected based on time constraints
• Unusual access patterns using tokens outside their expected validity windows

Detection Strategies

• Implement logging to capture JWT claim parsing errors and type mismatches
• Monitor authentication systems for tokens with malformed standard claims
• Audit application logs for validation bypass indicators where time-based checks were expected to fail
• Deploy application-level monitoring to detect JWT tokens with non-numeric time claims

Monitoring Recommendations

• Enable detailed logging for JWT validation processes in applications using jsonwebtoken
• Set up alerts for authentication events involving tokens with unexpected claim formats
• Review access logs for patterns indicating use of tokens outside their valid time windows
• Implement runtime detection for type confusion attempts in JWT payloads

How to Mitigate CVE-2026-25537

Immediate Actions Required

• Upgrade jsonwebtoken to version 10.3.0 or later immediately
• Review application code to ensure critical claims are included in required_spec_claims
• Audit existing JWT tokens in circulation for malformed claims
• Implement additional server-side validation for JWT time claims as defense-in-depth

Patch Information

The vulnerability has been addressed in jsonwebtoken version 10.3.0. The patch introduces a new InvalidClaimFormat error type that properly distinguishes between claims that are absent and claims that failed to parse due to type mismatches. With this fix, malformed claims will cause validation to fail rather than be silently skipped.

Update your Cargo.toml dependency:

[package]
name = "jsonwebtoken"
-version = "10.2.0"
+version = "10.3.0"
authors = ["Vincent Prouillet <hello@vincentprouillet.com>"]
license = "MIT"
readme = "README.md"

Source: GitHub Commit Update

For more details, see the GitHub Security Advisory GHSA-h395-gr6q-cpjc.

Workarounds

• Explicitly add all time-based claims (nbf, exp, iat) to required_spec_claims in your validation configuration
• Implement additional validation at the application layer to verify claim types before processing
• Consider implementing a pre-validation step that parses the JWT payload and verifies claim types
• Use schema validation on JWT payloads to reject tokens with incorrectly-typed claims before they reach the library

# Update jsonwebtoken in your Rust project
cargo update -p jsonwebtoken
# Verify the installed version
cargo tree -p jsonwebtoken