What is the CVSS score of CVE-2026-35042?

CVE-2026-35042 has a CVSS 3.1 base score of 7.5 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N. EPSS exploitation probability: 0.0%.

Which versions of RFC are affected by CVE-2026-35042?

The fast-jwt npm library (versions ≤3.3.3) contains a critical JWT validation bypass that allows unauthenticated attackers to forge authentication tokens, potentially granting unauthorized access to…

How to fix or mitigate CVE-2026-35042?

Within 24 hours: Identify all applications and services using fast-jwt library via dependency scanning (npm audit, Snyk, or equivalent) and document affected systems. Within 7 days: Contact the fast-jwt development team to confirm patch timeline; implement immediate compensating control by validating JWT tokens exclusively through an external hardened JWT library (e.g., jsonwebtoken with strict RFC 7515 enforcement) in a wrapper layer until patch release. Within 30 days: Deploy vendor-released patch to all identified instances immediately upon release, or migrate entirely to alternative JWT libraries with active security maintenance.

RFC CVE-2026-35042

HIGH

Insufficient Verification of Data Authenticity (CWE-345)

2026-04-03 https://github.com/nearform/fast-jwt

GHSA-hm7r-c7qw-ghp6

Authentication Bypass

7.5

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

7.5 HIGH

AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

High

Availability

None

Lifecycle Timeline

Analysis Generated

Apr 03, 2026 - 22:15 vuln.today

CVE Published

Apr 03, 2026 - 22:01 nvd

HIGH 7.5

DescriptionGitHub Advisory

Summary

fast-jwt does not validate the crit (Critical) Header Parameter defined in RFC 7515 §4.1.11. When a JWS token contains a crit array listing extensions that fast-jwt does not understand, the library accepts the token instead of rejecting it. This violates the MUST requirement in the RFC.

---

RFC Requirement

RFC 7515 §4.1.11:

> If any of the listed extension Header Parameters are not understood > and supported by the recipient, then the JWS is invalid.

---

Proof of Concept

javascript

const { createSigner, createVerifier } = require("fast-jwt"); // v3.3.3

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

// Should REJECT - x-custom-policy is not understood
const verifier = createVerifier({ key: "secret", algorithms: ["HS256"] });
try {
  const result = verifier(token);
  console.log("ACCEPTED:", result);
  // Output: ACCEPTED: { sub: 'attacker', role: 'admin' }
} catch (e) {
  console.log("REJECTED:", e.message);
}

Expected: Error - unsupported critical extension Actual: Token accepted.

Comparison

javascript

// jose (panva) v4+ - correctly rejects
const jose = require("jose");
await jose.jwtVerify(token, new TextEncoder().encode("secret"));
// throws: Extension Header Parameter "x-custom-policy" is not recognized

---

Impact

Split-brain verification in mixed-library environments
Security policy bypass when crit carries enforcement semantics
Token binding bypass (RFC 7800 cnf confirmation)
See CVE-2025-59420 for full impact analysis

---

Suggested Fix

In src/verifier.js, add crit validation after header decoding:

javascript

const SUPPORTED_CRIT = new Set(["b64"]);

function validateCrit(header) {
  if (!header.crit) return;
  if (!Array.isArray(header.crit) || header.crit.length === 0)
    throw new Error("crit must be a non-empty array");
  for (const ext of header.crit) {
    if (!SUPPORTED_CRIT.has(ext))
      throw new Error(`Unsupported critical extension: ${ext}`);
    if (!(ext in header))
      throw new Error(`Critical extension ${ext} not present in header`);
  }
}

AnalysisAI

JWT token validation bypass in fast-jwt npm library (all versions through 3.3.3) allows unauthenticated remote attackers to forge tokens with critical header parameters, achieving authentication bypass and security policy circumvention. The library violates RFC 7515 by accepting JWS tokens containing unrecognized 'crit' extensions that MUST be rejected per specification. No public exploit identified at time of analysis, though proof-of-concept code demonstrates trivial exploitation. CVSS 7.5 (Hi

Technical ContextAI

This vulnerability stems from incomplete RFC 7515 (JSON Web Signature) implementation in the fast-jwt library's token verification logic. RFC 7515 Section 4.1.11 defines the 'crit' (Critical) header parameter as a mandatory mechanism for signaling non-standard JWT extensions that verifiers MUST understand to accept the token. When a JWS contains a 'crit' array listing extensions like token binding confirmation ('cnf' per RFC 7800), custom policy enforcement, or other security-critical metadata, compliant verifiers must reject tokens if they don't support those extensions. The fast-jwt library's verifier.js module fails to implement this validation step entirely, accepting any token regardless of 'crit' contents. This is classified as CWE-345 (Insufficient Verification of Data Authenticity) because the library trusts cryptographic signatures without validating associated critical metadata. The vulnerability affects the npm package fast-jwt (pkg:npm/fast-jwt), contrasting with properly implementing libraries like jose (panva) v4+ that correctly enforce RFC 7515 Section 4.1.11 requirements.

RemediationAI

Organizations using fast-jwt should immediately audit JWT verification implementations to determine if critical header parameter validation is security-relevant in their architecture. Primary remediation requires monitoring the vendor repository at https://github.com/nearform/fast-jwt for patched release addressing GHSA-hm7r-c7qw-ghp6. Vendor advisory suggests implementing crit validation in src/verifier.js by maintaining a whitelist of supported critical extensions (initially containing only 'b64' per RFC 7515) and rejecting tokens containing unrecognized extensions. Interim workarounds include migrating to RFC 7515-compliant libraries like jose (https://github.com/panva/jose) version 4.0.0 or later, which correctly implements critical extension validation. For applications that cannot immediately migrate, implement application-layer validation by manually parsing JWT headers before fast-jwt verification and rejecting tokens containing 'crit' arrays, though this approach requires careful implementation to avoid introducing new vulnerabilities. Organizations should also review authorization logic to ensure security policies are not encoded in JWT header parameters that fast-jwt would ignore. Consult RFC 7515 Section 4.1.11 specification at https://www.rfc-editor.org/rfc/rfc7515.html#section-4.1.11 for complete implementation requirements.