CVE-2026-35041

fast-jwt provides fast JSON Web Token (JWT) implementation. From 5.0.0 to 6.2.0, 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 vulnerability is fixed in 6.2.1.

fast-jwt provides fast JSON Web Token (JWT) implementation. From 5.0.0 to 6.2.0, 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 vulnerability is fixed in 6.2.1.

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

<html> <body> <!--StartFragment--><h2 data-start="218" data-end="228">Summary</h2> <p data-start="230" data-end="364">A denial-of-service condition exists in <code data-start="270" data-end="280">fast-jwt</code> when the <code data-start="290" data-end="302">allowedAud</code> verification option is configured using a regular expression.</p> <p data-start="366" data-end="618">Because the <code data-start="378" data-end="383">aud</code> claim is attacker-controlled and the library evaluates it against the supplied <code data-start="463" data-end="471">RegExp</code>, a crafted JWT can trigger catastrophic backtracking in the JavaScript regex engine, resulting in significant CPU consumption during verification.</p> <p data-start="620" data-end="726">This occurs with a <strong data-start="639" data-end="661">validly signed JWT</strong>, making the issue exploitable in authenticated contexts such as:</p> <ul data-start="728" data-end="855"> <li data-start="728" data-end="744"> <p data-start="730" data-end="744">API gateways</p> </li> <li data-start="745" data-end="774"> <p data-start="747" data-end="774">authentication middleware</p> </li> <li data-start="775" data-end="811"> <p data-start="777" data-end="811">service-to-service communication</p> </li> <li data-start="812" data-end="855"> <p data-start="814" data-end="855">OAuth / OIDC token validation pipelines</p> </li> </ul> <hr data-start="857" data-end="860"> <h2 data-start="862" data-end="883">Affected Component</h2> <ul data-start="885" data-end="1035"> <li data-start="885" data-end="910"> <p data-start="887" data-end="910"><strong data-start="887" data-end="899">Library:</strong> fast-jwt</p> </li> <li data-start="911" data-end="940"> <p data-start="913" data-end="940"><strong data-start="913" data-end="932">Version tested:</strong> 6.1.0</p> </li> <li data-start="941" data-end="974"> <p data-start="943" data-end="974"><strong data-start="943" data-end="955">Runtime:</strong> Node.js v24.13.1</p> </li> <li data-start="975" data-end="1035"> <p data-start="977" data-end="1035"><strong data-start="977" data-end="989">Feature:</strong> claim validation using <code data-start="1013" data-end="1033">allowedAud: RegExp</code></p> </li> </ul> <hr data-start="1037" data-end="1040"> <h2 data-start="1042" data-end="1051">Impact</h2> <p data-start="1053" data-end="1091"><strong data-start="1053" data-end="1091">CPU exhaustion / Denial of Service</strong></p> <p data-start="1093" data-end="1203">A crafted JWT causes verification to take multiple seconds per request due to catastrophic regex backtracking.</p> <h3 data-start="1205" data-end="1236">Measured verification times</h3> <div class="TyagGW_tableContainer"><div tabindex="-1" class="group TyagGW_tableWrapper flex flex-col-reverse w-fit"> Input size (n) | Verification time -- | -- 24 | ~123 ms 28 | ~1.97 s 30 | ~7.85 s

</div></div> <p data-start="1339" data-end="1361">This is sufficient to:</p> <ul data-start="1363" data-end="1546"> <li data-start="1363" data-end="1399"> <p data-start="1365" data-end="1399">block…

fast-jwt provides fast JSON Web Token (JWT) implementation. From 5.0.0 to 6.2.0, 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 vulnerability is fixed in 6.2.1.

fast-jwt provides fast JSON Web Token (JWT) implementation. From 5.0.0 to 6.2.0, 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 vulnerability is fixed in 6.2.1.

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

<html> <body> <!--StartFragment--><h2 data-start="218" data-end="228">Summary</h2> <p data-start="230" data-end="364">A denial-of-service condition exists in <code data-start="270" data-end="280">fast-jwt</code> when the <code data-start="290" data-end="302">allowedAud</code> verification option is configured using a regular expression.</p> <p data-start="366" data-end="618">Because the <code data-start="378" data-end="383">aud</code> claim is attacker-controlled and the library evaluates it against the supplied <code data-start="463" data-end="471">RegExp</code>, a crafted JWT can trigger catastrophic backtracking in the JavaScript regex engine, resulting in significant CPU consumption during verification.</p> <p data-start="620" data-end="726">This occurs with a <strong data-start="639" data-end="661">validly signed JWT</strong>, making the issue exploitable in authenticated contexts such as:</p> <ul data-start="728" data-end="855"> <li data-start="728" data-end="744"> <p data-start="730" data-end="744">API gateways</p> </li> <li data-start="745" data-end="774"> <p data-start="747" data-end="774">authentication middleware</p> </li> <li data-start="775" data-end="811"> <p data-start="777" data-end="811">service-to-service communication</p> </li> <li data-start="812" data-end="855"> <p data-start="814" data-end="855">OAuth / OIDC token validation pipelines</p> </li> </ul> <hr data-start="857" data-end="860"> <h2 data-start="862" data-end="883">Affected Component</h2> <ul data-start="885" data-end="1035"> <li data-start="885" data-end="910"> <p data-start="887" data-end="910"><strong data-start="887" data-end="899">Library:</strong> fast-jwt</p> </li> <li data-start="911" data-end="940"> <p data-start="913" data-end="940"><strong data-start="913" data-end="932">Version tested:</strong> 6.1.0</p> </li> <li data-start="941" data-end="974"> <p data-start="943" data-end="974"><strong data-start="943" data-end="955">Runtime:</strong> Node.js v24.13.1</p> </li> <li data-start="975" data-end="1035"> <p data-start="977" data-end="1035"><strong data-start="977" data-end="989">Feature:</strong> claim validation using <code data-start="1013" data-end="1033">allowedAud: RegExp</code></p> </li> </ul> <hr data-start="1037" data-end="1040"> <h2 data-start="1042" data-end="1051">Impact</h2> <p data-start="1053" data-end="1091"><strong data-start="1053" data-end="1091">CPU exhaustion / Denial of Service</strong></p> <p data-start="1093" data-end="1203">A crafted JWT causes verification to take multiple seconds per request due to catastrophic regex backtracking.</p> <h3 data-start="1205" data-end="1236">Measured verification times</h3> <div class="TyagGW_tableContainer"><div tabindex="-1" class="group TyagGW_tableWrapper flex flex-col-reverse w-fit"> Input size (n) | Verification time -- | -- 24 | ~123 ms 28 | ~1.97 s 30 | ~7.85 s

</div></div> <p data-start="1339" data-end="1361">This is sufficient to:</p> <ul data-start="1363" data-end="1546"> <li data-start="1363" data-end="1399"> <p data-start="1365" data-end="1399">block…