CVE-2026-35042: 
JavaScript vulnerability analysis and mitigation

CVE-2026-35042 is a JWT validation bypass vulnerability in the fast-jwt npm library (by NearForm) caused by failure to validate the crit (Critical) Header Parameter as required by RFC 7515 §4.1.11. When a JWS token includes a crit array listing extensions that fast-jwt does not understand, the library incorrectly accepts the token instead of rejecting it, violating the RFC's MUST requirement. All versions up to and including 6.1.0 are affected; version 6.2.0 contains the fix. The vulnerability carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, NearForm Advisory).

The root cause is classified under CWE-345 (Insufficient Verification of Data Authenticity) and CWE-636 (Not Failing Securely / Failing Open). RFC 7515 §4.1.11 mandates that if any extension listed in the crit header array is not understood by the recipient, the JWS token MUST be treated as invalid. The fast-jwt verifier in src/verifier.js does not perform this check after decoding the header, so tokens carrying arbitrary unrecognized critical extensions (e.g., x-custom-policy) are silently accepted. A public proof-of-concept demonstrates this by crafting a signed token with a crit: ["x-custom-policy"] header and showing that createVerifier accepts it without error, while compliant libraries such as jose (panva) correctly reject it (GitHub Advisory, NearForm Advisory).

Successful exploitation allows an unauthenticated network attacker to forge or manipulate JWS tokens that carry security-enforcement semantics in the crit header, causing the application to accept tokens it should reject. Concrete consequences include security policy bypass (e.g., bypassing MFA enforcement encoded in a custom critical extension), token binding bypass (RFC 7800 cnf confirmation), and split-brain verification inconsistencies in environments that mix fast-jwt with RFC-compliant JWT libraries. The integrity impact is rated High, with no direct confidentiality or availability impact (GitHub Advisory, NearForm Advisory).

A JavaScript proof-of-concept is publicly available in the GitHub Security Advisory, demonstrating that a crafted token with an unrecognized crit extension is accepted by the vulnerable verifier. The EPSS score is approximately 0.014% (0.000140), indicating low current exploitation probability. There is no evidence of active in-the-wild exploitation at this time, and the vulnerability is not listed in the CISA KEV catalog. No threat actor attribution has been reported (GitHub Advisory, Feedly).

1. Identify target: Determine that the target application uses fast-jwt version ≤ 6.1.0 for JWT verification (e.g., via package.json or npm list fast-jwt if accessible, or by observing JWT structure in API responses).
2. Craft a malicious token: Using any valid signing key accepted by the target (or a known shared secret), create a JWS token that includes a crit array with one or more unrecognized extension names and corresponding header fields encoding desired policy values:

const { createSigner } = require("fast-jwt");
const signer = createSigner({ key: "secret", algorithm: "HS256" });
const token = signer({
  sub: "attacker",
  role: "admin",
  header: { crit: ["x-custom-policy"], "x-custom-policy": "require-mfa" }
});

3. Submit the token: Send the crafted token to the target API endpoint in the Authorization: Bearer <token> header.
4. Bypass enforcement: Because fast-jwt does not validate the crit extensions, the token is accepted. Any security policy that was supposed to be enforced via the critical extension (e.g., MFA requirement, token binding) is silently bypassed, granting the attacker access with the claims embedded in the token payload (GitHub Advisory, NearForm Advisory).

• Network: Incoming API requests bearing JWTs with a crit header field containing extension names not recognized by the application (detectable via JWT header inspection in API gateway or WAF logs).
• Logs: Application logs showing successful authentication or authorization for requests where the decoded JWT header contains a non-empty crit array; absence of rejection errors for tokens with unknown critical extensions.
• File System / Dependency: Presence of fast-jwt version ≤ 6.1.0 in node_modules/fast-jwt/package.json or package-lock.json.
• Behavioral: Unexpected privilege escalation or policy bypass (e.g., MFA-exempt access) for accounts whose tokens carry custom crit header parameters (GitHub Advisory).

Upgrade fast-jwt to version 6.2.0 or later, which adds proper crit header validation in src/verifier.js. As a temporary workaround prior to upgrading, implement application-level validation that inspects the decoded JWT header and rejects any token containing a crit array with extensions not explicitly supported by your application. Additionally, audit all services that depend on fast-jwt for JWT verification and review whether any security policies are encoded in crit headers that may have been bypassable (NearForm Advisory, GitHub Advisory).

The advisory notes that this is the same class of vulnerability as CVE-2025-59420 (Authlib crit bypass, CVSS 7.5), suggesting a broader pattern of JWT libraries failing to enforce RFC 7515 §4.1.11. Brief social media coverage appeared on Mastodon via @thehackerwire and on Bluesky shortly after the NVD publication. No major vendor statements or significant researcher commentary beyond the advisory itself have been identified (NearForm Advisory).