CVE-2026-35041: Regular Expression Denial of Service in fast-jwt

fast-jwt is a Node.js library responsible for signing and verifying JSON Web Tokens. The library supports customizable validation for specific JWT claims, such as aud (audience) and iss (issuer). This design allows developers to supply standard JavaScript RegExp objects for dynamic pattern matching during the token verification phase.

A Regular Expression Denial of Service (ReDoS) vulnerability, tracked as CWE-1333, exists in this claim verification logic. Versions 5.0.0 through 6.2.0 of fast-jwt do not validate the complexity or safety of the developer-supplied regular expressions prior to execution. The library implicitly trusts the configuration provided by the application owner.

This design oversight allows the underlying JavaScript V8 engine to attempt exponential evaluations when processing specific token claims against vulnerable patterns. The resulting evaluation blocks the main event loop, causing immediate degradation of service and subsequent application unavailability.

The defect stems from the lack of input sanitization on developer-supplied RegExp patterns passed into the token verifier configuration. Options such as allowedAud, allowedIss, allowedSub, allowedJti, and allowedNonce accept these expressions to validate token claims dynamically.

When a regular expression contains grouping with repetition, such as /(a+)+X$/, the regex engine utilizes a nondeterministic finite automaton (NFA) approach to evaluate matches. If the token claim contains a payload that partially matches the expression but ultimately fails to meet the termination condition, the engine attempts every possible permutation of the repetitive sequence.

This mechanism is known as catastrophic backtracking. Because Node.js runs on a single-threaded event loop, the excessive computational overhead from backtracking blocks all concurrent operations. The execution context remains trapped within the regex evaluation routine until the maximum stack depth is reached or the engine exhausts available resources.

Prior to version 6.2.1, the library blindly executed regex.test(claimValue) without analyzing the internal structure of the RegExp object. This implementation placed the burden of regex safety entirely on the application developer, providing no failsafe against overly complex patterns.

The patch introduced in commit b0be0ca161593836a153d5180ca5358ad9b5de94 resolves this defect by integrating the safe-regex2 package. The maintainers implemented a checkForUnsafeRegExp helper function invoked during the initialization of the token verifier.

// Patched code from src/verifier.js
const safeRegex = require('safe-regex2')
 
function checkForUnsafeRegExp(raw, optionName) {
  const patterns = Array.isArray(raw) ? raw : [raw]
  for (const r of patterns) {
    if (r instanceof RegExp && !safeRegex(r)) {
      process.emitWarning(
        `The ${optionName} option contains an unsafe RegExp ${r} that may cause a ReDoS attack. Please review it. ` +
          'See https://github.com/nearform/fast-jwt/security/advisories/GHSA-cjw9-ghj4-fwxf for details.',
        { code: 'FAST_JWT_UNSAFE_REGEXP' }
      )
    }
  }
}

Additionally, commit 18d25904e4617e8753526d1b3ab5a2cccdea726a mitigates a separate statefulness vulnerability by resetting r.lastIndex = 0 prior to every test execution. This modification ensures that regex objects initialized with the /g or /y flags do not persist state across multiple validation invocations, guaranteeing deterministic evaluation.

Exploitation of this vulnerability requires specific environmental prerequisites. The targeted application must actively utilize fast-jwt and must initialize the verifier with a vulnerable regular expression for at least one claim property. The attacker cannot inject the regex pattern; they can only supply the input evaluated against it.

The attacker must supply a JWT containing a maliciously crafted claim string that triggers the catastrophic backtracking scenario. Because the regex evaluation occurs strictly after the cryptographic signature of the token is verified, the attacker must possess a token that the server considers cryptographically valid.

This valid token must either be generated by a trusted issuer or signed using a compromised cryptographic key. Once the application receives the token, the V8 engine evaluates the crafted claim against the unsafe pattern, immediately causing the CPU core to spike to 100% utilization. The Node.js instance subsequently stops processing new incoming HTTP requests.

The primary security impact is a localized Denial of Service (DoS) resulting in the complete unavailability of the affected Node.js process. Because JavaScript execution is single-threaded, a single malicious JWT renders the entire process unresponsive to all users sharing that instance.

The vulnerability holds a CVSS v3.1 base score of 4.2. The metric reflects a High Attack Complexity (AC:H) because the application must be misconfigured with an unsafe regex. It also factors in High Privileges Required (PR:H) because the payload must reside within a validly signed token.

Despite the low numerical score, the operational impact on microservice architectures can be severe. In deployments lacking robust health checking and auto-remediation, a single malicious request permanently disables the service pod. The vulnerability does not permit data exfiltration, memory corruption, or remote code execution.

The primary remediation strategy requires upgrading the fast-jwt dependency to version 6.2.1 or later. The patched version enforces static analysis of all provided regular expressions and logs explicit process warnings when developers supply unsafe patterns during verifier initialization.

Software engineering teams must audit their usage of the createVerifier function. Developers should replace complex RegExp objects with strict string equality checks or simple prefix validations whenever the business logic permits. Avoiding regex entirely for standard claims eliminates the attack surface.

If regular expressions remain a strict requirement, teams must implement CI/CD checks utilizing tools like eslint-plugin-regexp or safe-regex2 to identify and reject catastrophic backtracking patterns before deployment. Active runtime monitoring should also capture and alert on the FAST_JWT_UNSAFE_REGEXP warning code to identify flawed configurations in production.