CVE-2026-35040
Received Received - Intake
Stateful RegExp Modifier Causes JWT Verification Failures in fast-jwt

Publication date: 2026-04-09

Last updated on: 2026-04-17

Assigner: GitHub, Inc.

Description
fast-jwt provides fast JSON Web Token (JWT) implementation. Prior to 6.2.1, using certain modifiers on RegExp objects in the allowedAud, allowedIss, allowedSub, allowedJti, or allowedNonce options in verify functions can cause certain unintended behaviours. This is because some modifiers are stateful and will cause failures in every second verification attempt regardless of the validity of the token provided. Such modifiers are /g (global matching) and /y (sticky matching). This does NOT allow invalid tokens to be accepted, only for valid tokens to be improperly rejected in some configurations. Instead it causes 50% of valid authentication requests to fail in an alternating pattern. This vulnerability is fixed in 6.2.1.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-04-09
Last Modified
2026-04-17
Generated
2026-05-07
AI Q&A
2026-04-09
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
nearform fast-jwt to 6.2.1 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-697 The product compares two entities in a security-relevant context, but the comparison is incorrect.
CWE-440 A feature, API, or function does not perform according to its specification.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

CVE-2026-35040 is a vulnerability in the fast-jwt library where using certain stateful regular expression modifiers (/g for global matching and /y for sticky matching) in allowed claim validation options causes non-deterministic verification results.

Because these RegExp objects maintain internal state (the lastIndex property), repeated calls to verify the same valid token can alternate between success and failure, causing about 50% of valid authentication attempts to fail unpredictably.

This happens specifically when these stateful RegExp objects are used in allowedAud, allowedIss, allowedSub, allowedJti, or allowedNonce options during JWT verification.

The vulnerability does not allow invalid tokens to be accepted, only valid tokens to be intermittently rejected.

The issue was fixed by resetting the RegExp object's lastIndex property to zero before each test call, ensuring deterministic validation.


How can this vulnerability impact me? :

This vulnerability can cause approximately 50% of valid authentication requests to fail intermittently, leading to unreliable authentication behavior.

  • Logical Denial of Service (DoS) due to authentication flapping.
  • Intermittent user authentication failures causing poor user experience.
  • Potential retry storms and cascading failures in API gateways or authentication middleware.
  • Operational monitoring alerts triggered by unpredictable authentication outcomes.

How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability manifests as intermittent authentication failures where approximately 50% of valid authentication requests fail in an alternating pattern due to stateful RegExp flags (/g or /y) used in allowed claim validations.

To detect this issue, monitor authentication logs or API gateway logs for repeated authentication failures that occur in a roughly alternating pattern for the same valid tokens.

A proof of concept involves repeatedly verifying the same JWT token using the fast-jwt library configured with allowed claim options that use RegExp objects with /g or /y flags. The verification calls will alternate between PASS and FAIL.

While no specific network or system commands are provided, you can test your system by running a script that repeatedly verifies a valid JWT token against your fast-jwt verifier configured with RegExp patterns using /g or /y flags and observe if verification results alternate.


What immediate steps should I take to mitigate this vulnerability?

The immediate mitigation is to remove the use of stateful RegExp modifiers /g (global) and /y (sticky) from any allowed claim validation options (allowedAud, allowedIss, allowedSub, allowedJti, allowedNonce) in your fast-jwt configuration.

Alternatively, upgrade the fast-jwt library to version 6.2.1 or later, where the vulnerability is fixed by resetting the RegExp object's lastIndex property before each test call.

Until the patched version is adopted, avoid using RegExp patterns with /g or /y flags in allowed claim validations to prevent intermittent authentication failures.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

The vulnerability in fast-jwt causes intermittent authentication failures due to non-deterministic validation of allowed claims when using stateful RegExp modifiers. This leads to approximately 50% of valid authentication requests failing in an alternating pattern, effectively causing a logical denial of service.

While the vulnerability does not allow invalid tokens to be accepted, the unreliable authentication behavior can impact system availability and user access reliability.

Regarding compliance with standards like GDPR or HIPAA, the vulnerability does not directly compromise confidentiality or integrity of data, as it does not allow unauthorized access or data leakage.

However, the intermittent denial of service and authentication failures could affect availability aspects of these regulations, potentially impacting user access to protected resources or services.

Organizations relying on fast-jwt for authentication should consider this impact on availability and ensure timely patching to maintain compliance with availability requirements in such standards.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart