CVE-2026-35040: 
JavaScript vulnerability analysis and mitigation

CVE-2026-35040 is a logical denial-of-service vulnerability in the fast-jwt npm package (by NearForm) caused by stateful RegExp modifiers in JWT claim validation options. When applications configure allowedAud, allowedIss, allowedSub, allowedJti, or allowedNonce with RegExp objects using the /g (global) or /y (sticky) flags, the verifier produces non-deterministic results — rejecting valid tokens in an alternating PASS/FAIL pattern (~50% failure rate). All versions prior to 6.2.1 are affected. The vulnerability was disclosed on April 9, 2026, with a CVSS v3.1 base score of 5.3 (Medium) (Github Advisory, Security Advisory).

The root cause lies in JavaScript's RegExp.prototype.test() being stateful when the /g or /y flags are set — each invocation mutates the lastIndex property on the RegExp object. In src/verifier.js, the ensureStringClaimMatcher() function returned RegExp objects directly, and validateClaimValues() called .test() on them repeatedly via allowed.some(a => a.test(v)) without resetting lastIndex. This causes every second call to fail for a perfectly valid token. The vulnerability is classified as CWE-440 (Expected Behavior Violation) and CWE-697 (Incorrect Comparison), and only affects deployments explicitly using RegExp objects with stateful modifiers in the allowed* claim options — string-based patterns are unaffected (Security Advisory, Fix PR).

The vulnerability causes a logical denial-of-service affecting authentication availability: approximately 50% of valid JWT authentication requests are incorrectly rejected in an alternating pattern, leading to intermittent user authentication failures. This can trigger retry storms in API gateways and authentication middleware, cascade into broader service degradation, and generate false-positive operational alerts. There is no confidentiality or integrity impact — invalid tokens cannot be accepted as a result of this flaw (Github Advisory).

A public proof-of-concept (PoC) Node.js script is available in the official security advisory, demonstrating the alternating PASS/FAIL behavior across all affected allowed* claim options (Security Advisory). There is no evidence of in-the-wild exploitation at this time, and no threat actor attribution has been reported. The EPSS score is approximately 0.061% (0.182% per GitHub Advisory), placing it in the lower percentiles for near-term exploitation likelihood. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.

1. Identify target: Determine that the target application uses fast-jwt versions prior to 6.2.1 and configures any allowed* claim option (e.g., allowedAud, allowedIss) with a RegExp using the /g or /y flag.
2. Obtain a valid JWT: Acquire or generate a legitimately signed JWT token that satisfies the application's claim requirements (e.g., correct audience, issuer).
3. Send repeated requests: Submit the valid JWT token in rapid succession to the target authentication endpoint. Due to the stateful lastIndex mutation, every second verification call will fail.
4. Observe alternating rejections: The server will reject the valid token on every other request (PASS/FAIL/PASS/FAIL pattern), causing authentication failures for legitimate users without any token manipulation.
5. Amplify impact: At scale, sending many concurrent valid requests will cause ~50% of authentication attempts to fail, potentially triggering retry storms and cascading failures in dependent services (Security Advisory).

• Logs: Intermittent JWT verification errors (e.g., FAST_JWT_* error codes) for the same valid token in application logs, appearing in a strict alternating pattern with successful verifications.
• Application Behavior: Authentication failure rate hovering near 50% for a specific user or token, with no corresponding token expiry or signature issues; retry storms visible in API gateway or load balancer access logs.
• Monitoring Alerts: Sudden spike in authentication failure alerts without corresponding changes in user behavior, token issuance, or infrastructure — particularly affecting endpoints that use RegExp-based claim validation.

Upgrade fast-jwt to version 6.2.1 or later, which wraps RegExp matchers in ensureStringClaimMatcher() to reset lastIndex = 0 before each .test() call, making validation deterministic (Release v6.2.1, Fix PR). As an immediate workaround without upgrading, remove the /g or /y flags from any RegExp used in allowedAud, allowedIss, allowedSub, allowedJti, or allowedNonce options — for example, replace allowedAud: /^admin$/g with allowedAud: /^admin$/. Applications using string-based patterns for these options are not affected and require no changes (Github Advisory).