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

⚠️ 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

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.