Skip to content

fast-jwt has a ReDoS when using RegExp in allowed* leading to CPU exhaustion during token verification

Moderate severity GitHub Reviewed Published Apr 9, 2026 in nearform/fast-jwt • Updated Apr 9, 2026

Package

npm fast-jwt (npm)

Affected versions

>= 5.0.0, <= 6.2.0

Patched versions

6.2.1

Description

⚠️ IMPORTANT CLARIFICATIONS

Affected Configurations

This vulnerability ONLY affects applications that:

  • Use RegExp objects (not strings) in the allowedAud, allowedIss, allowedSub, allowedJti, or allowedNonce options
  • Configure patterns susceptible to catastrophic backtracking
  • Example: allowedAud: /^(a+)+X$/ ← VULNERABLE
  • Example: allowedAud: "api.company.com" ← SAFE

Not Affected

  • Applications using string patterns for audience validation (most common)
  • Applications using safe RegExp patterns without nested quantifiers
  • Default fast-jwt configurations

Assessment Guide

To determine if you're affected:

  1. Check ifallowedAud, allowedIss, allowedSub, allowedJti, or allowedNonce use RegExp objects (/pattern/ or new RegExp())
  2. If yes, review the pattern for nested quantifiers like (a+)+, (.*)*, etc.
  3. If no RegExp usage, you are NOT affected

Summary

A denial-of-service condition exists in fast-jwt when the allowedAud verification option is configured using a regular expression.

Because the aud claim is attacker-controlled and the library evaluates it against the supplied RegExp, a crafted JWT can trigger catastrophic backtracking in the JavaScript regex engine, resulting in significant CPU consumption during verification.

This occurs with a validly signed JWT, making the issue exploitable in authenticated contexts such as:

  • API gateways

  • authentication middleware

  • service-to-service communication

  • OAuth / OIDC token validation pipelines


Affected Component

  • Library: fast-jwt

  • Version tested: 6.1.0

  • Runtime: Node.js v24.13.1

  • Feature: claim validation using allowedAud: RegExp


Impact

CPU exhaustion / Denial of Service

A crafted JWT causes verification to take multiple seconds per request due to catastrophic regex backtracking.

Measured verification times

Input size (n) | Verification time -- | -- 24 | ~123 ms 28 | ~1.97 s 30 | ~7.85 s

This is sufficient to:

  • block Node.js event loop threads

  • degrade API throughput

  • cause cascading service failures

  • increase serverless execution costs

  • saturate authentication infrastructure


Root Cause

The library allows regular expressions in claim validation:

allowedAud: /^(a+)+X$/

The aud claim is attacker-controlled:

aud = "a".repeat(n) + "Y"

This creates catastrophic backtracking in the JavaScript regex engine.

Verification time grows exponentially as input length increases.


Exploitability

Attack requires:

  • a valid signed JWT (post-authentication context)

  • attacker control over the aud claim

  • a vulnerable regex configured by the application

Common real-world scenarios

  • shared HS secrets

  • internal JWT issuance

  • microservice authentication

  • OAuth / OIDC custom audiences

  • internal service tokens


Proof of Concept

Reproduction steps

  1. Install fast-jwt

  2. Configure verifier with a RegExp in allowedAud

  3. Send a valid signed JWT with adversarial aud

Attached artifacts

  • poc-suite-redos-fastjwt.js

  • evidence-redos-fastjwt.json

Observed behavior

Verification CPU time increases from milliseconds to multiple seconds as input length grows.


Security Classification

  • CWE-1333: Inefficient Regular Expression

  • CWE-400: Uncontrolled Resource Consumption

  • Class: Authenticated Denial of Service


Expected Behavior

The library should prevent unbounded CPU work on attacker-controlled claims.

Possible mitigations

  • safe-regex validation

  • maximum length enforcement for claims

  • regex complexity limits

  • documentation warning about ReDoS risks when using RegExp-based validation


Notes

Signature verification occurs before claim validation, therefore this is not a pre-authentication DoS.

However, the vulnerability remains exploitable in authenticated or token-bearing contexts and can significantly impact production environments.

### References - https://github.com/nearform/fast-jwt/security/advisories/GHSA-cjw9-ghj4-fwxf - https://github.com/nearform/fast-jwt/pull/595 - https://github.com/nearform/fast-jwt/commit/b0be0ca161593836a153d5180ca5358ad9b5de94 - https://github.com/nearform/fast-jwt/releases/tag/v6.2.1 - https://nvd.nist.gov/vuln/detail/CVE-2026-35041
@antoatta85 antoatta85 published to nearform/fast-jwt Apr 9, 2026
Published by the National Vulnerability Database Apr 9, 2026
Published to the GitHub Advisory Database Apr 9, 2026
Reviewed Apr 9, 2026
Last updated Apr 9, 2026

Severity

Moderate

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
High
Privileges required
High
User interaction
Required
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

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:H/PR:H/UI:R/S:U/C:N/I:N/A:H

EPSS score

Exploit Prediction Scoring System (EPSS)

This score estimates the probability of this vulnerability being exploited within the next 30 days. Data provided by FIRST.
(9th percentile)

Weaknesses

Inefficient Regular Expression Complexity

The product uses a regular expression with an inefficient, possibly exponential worst-case computational complexity that consumes excessive CPU cycles. Learn more on MITRE.

CVE ID

CVE-2026-35041

GHSA ID

GHSA-cjw9-ghj4-fwxf

Source code

Credits

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