CVE-2026-35039: 
JavaScript vulnerability analysis and mitigation

CVE-2026-35039 is a cache confusion vulnerability in the fast-jwt Node.js library (npm package by NearForm) that allows JWT token misidentification during verification when a collision-prone custom cacheKeyBuilder function is used alongside caching. Disclosed on April 2, 2026, it affects fast-jwt versions 0.0.1 through 6.1.x, with the patched version being 6.2.0. The vulnerability carries a CVSS v3.1 base score of 9.1 (Critical) (GitHub Advisory, NearForm Advisory).

The root cause lies in src/verifier.js, where the verifier uses the output of a user-supplied cacheKeyBuilder function as the sole cache lookup key without binding or re-validating the cached payload against the actual token being verified (CWE-345, CWE-706, CWE-1289). When two distinct valid JWTs produce the same cache key — for example, by keying only on aud or using a static/grouped key — the verifier returns the cached payload from the first token for all subsequent tokens sharing that key, without re-verifying the signature or re-decoding the payload. Exploitation requires no special privileges or user interaction; an attacker simply needs to present a valid JWT that collides with a previously cached token's key. A public proof-of-concept is included in the advisory itself, demonstrating that verifying userB's token returns userA's claims when a static or audience-only key builder is used (GitHub Advisory, NearForm Advisory).

Successful exploitation causes severe authentication and authorization bypass: a user presenting a valid JWT may receive the identity, claims, and permissions of a different user whose token was previously cached under the same key. This enables user impersonation (UserB inherits UserA's identity), privilege escalation (low-privilege users inherit admin-level access), cross-tenant data access, and incorrect RBAC evaluation — all without any cryptographic weakness in the tokens themselves. The impact is highest in API gateways, authentication middleware, and multi-tenant environments where authorization decisions are driven by sub, aud, or iss claims from the verified payload (GitHub Advisory).

A proof-of-concept is publicly available within the GitHub Security Advisory itself, demonstrating the collision scenario with reproducible Node.js code. As of the time of disclosure, there is no evidence of active in-the-wild exploitation or threat actor attribution (NearForm Advisory). The EPSS score is approximately 0.023% (6th percentile), indicating low current exploitation probability. The vulnerability is not listed in the CISA KEV catalog. Exploitation is constrained to applications that both enable caching and use a collision-prone custom cacheKeyBuilder, limiting the affected population (GitHub Advisory).

1. Identify a vulnerable application: Locate a Node.js application using fast-jwt versions < 6.2.0 with cache: true (or a numeric cache size) and a custom cacheKeyBuilder that groups tokens by non-unique attributes (e.g., aud, iss, or a static string).
2. Obtain a valid JWT for a low-privilege account: Authenticate as a regular user to receive a valid JWT (e.g., sub: 'userB', aud: 'admin').
3. Trigger cache population by a privileged user: Ensure that a privileged user's token (e.g., sub: 'userA', aud: 'admin') has already been verified and cached — this may happen naturally in a shared-cache environment or can be triggered by causing the target user to authenticate first.
4. Present the low-privilege token: Submit the attacker's valid JWT to the application's verification endpoint. Because the cacheKeyBuilder produces the same key (e.g., aud=admin) for both tokens, the verifier returns the cached payload from userA instead of userB.
5. Receive elevated claims: The application receives userA's claims (including elevated sub, roles, or permissions) and makes authorization decisions based on the wrong identity, granting the attacker userA's access rights (GitHub Advisory, NearForm Advisory).

• Logs: Application logs showing a user (sub claim) performing actions inconsistent with their account history or role; authorization decisions logged for a sub value that does not match the presented JWT's actual subject.
• Application Behavior: Users reporting access to resources or data belonging to other accounts; RBAC enforcement granting permissions not assigned to the authenticated user.
• Process/Runtime: Node.js process emitting FAST_JWT_CACHE_KEY_BUILDER_SECURITY_RISK warnings at startup (added in the patched version 6.2.0) — presence of this warning in older deployments indicates a vulnerable configuration is in use (Patch Commit).
• Configuration Audit: Presence of a custom cacheKeyBuilder function in createVerifier configuration combined with cache: true or a numeric cache size in the application source code.

The primary remediation is to upgrade fast-jwt to version 6.2.0 or later, which adds a runtime warning (FAST_JWT_CACHE_KEY_BUILDER_SECURITY_RISK) when a custom cacheKeyBuilder is used with caching enabled, and updates documentation to warn users of the risk (Patch Commit). If immediate upgrade is not possible, apply one of these workarounds in priority order: (1) Remove the custom cacheKeyBuilder and rely on the default hash-based implementation, which is safe; (2) Update the custom cacheKeyBuilder to include unique per-token identifiers such as sub, aud, and iat combined (e.g., `${sub}-${aud}-${iat}`); or (3) Disable caching entirely by setting cache: false. Multi-tenant environments should treat this as a critical patch given the cross-tenant data access risk (GitHub Advisory).

The NearForm maintainers noted in the advisory that the vulnerability is created by developer-supplied code rather than the library itself, and opted to add documentation warnings and a runtime process.emitWarning rather than a deeper architectural fix, stating: "since the defaults work we will not be updating the library beyond that for this advisory" (NearForm Advisory). The Hacker Wire published a dedicated write-up on the vulnerability titled "fast-jwt Cache Collision CVE-2026-35039 Leads to JWT Misidentification" (The Hacker Wire). The issue was also discussed on Mastodon and Bluesky, with community attention focused on the design tension between exposing performance-tuning extension points and enforcing security invariants in authentication libraries.