Skip to content

fast-jwt accepts unknown `crit` header extensions (RFC 7515 violation)

High severity GitHub Reviewed Published Apr 2, 2026 in nearform/fast-jwt • Updated Apr 4, 2026

Package

npm fast-jwt (npm)

Affected versions

<= 6.1.0

Patched versions

None

Description

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

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

// 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:

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`);
  }
}

References

@antoatta85 antoatta85 published to nearform/fast-jwt Apr 2, 2026
Published to the GitHub Advisory Database Apr 3, 2026
Reviewed Apr 3, 2026
Last updated Apr 4, 2026

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
High
Availability
None

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

EPSS score

Weaknesses

Insufficient Verification of Data Authenticity

The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data. Learn more on MITRE.

Not Failing Securely ('Failing Open')

When the product encounters an error condition or failure, its design requires it to fall back to a state that is less secure than other options that are available, such as selecting the weakest encryption algorithm or using the most permissive access control restrictions. Learn more on MITRE.

CVE ID

CVE-2026-35042

GHSA ID

GHSA-hm7r-c7qw-ghp6

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.