CVE-2026-35039
CRITICAL
GHSA-rp9m-7r4c-75qg
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessDeploy application with weak cacheKeyBuilder
-
DeliverySubmit authentication requests with different tokens
-
ExploitTrigger cache collision in token verification
-
ExecutionExtract claims from mismatched cached token
-
ImpactAssume identity of different user
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A08:2025 - Software or Data Integrity Failures
ASVS 5.0
V15 - Secure Coding and Architecture Data authenticity verification
|
| Exploitation Conditions | Requires custom cacheKeyBuilder implementation that fails to generate unique keys per token. Attacker needs network access to submit tokens that collide in cache. No authentication or user interaction required. Affects applications using vulnerable token caching logic. |
| Impact | Real-world risk is HIGH for affected configurations but LIMITED in scope. The CVSS 9.1 (Critical) rating reflects severe potential impact: network-accessible (AV:N), low complexity (AC:L), no privileges required (PR:N), with high confidentiality and integrity impact. However, exploitation requires a very specific configuration-both caching enabled AND a poorly designed custom cacheKeyBuilder-making this a developer-introduced vulnerability rather than a default-state flaw. The GitHub advisory confirms patch availability, reducing remediation friction. No KEV listing or public exploit code exists, suggesting exploitation has not occurred at scale, but the technical simplicity (AC:L) means any affected application could be exploited trivially once identified. SSVC assessment: exploitation status is none confirmed, technical impact is total (user impersonation/privilege escalation), automatable is yes (once vulnerable config identified). Priority depends on deployment prevalence-organizations should audit fast-jwt usage immediately, but the subset of truly vulnerable deployments is likely small given the requirement for custom, flawed cacheKeyBuilder implementations. |
| Exploit ScenarioDerived | An attacker authenticates as a low-privilege user and obtains a valid JWT from the application's identity provider. The application uses fast-jwt with a custom cacheKeyBuilder that groups tokens by audience type (admin-users vs regular-users). When an administrator authenticates and their high-privilege token is verified and cached under the 'admin-users' key, the attacker presents their own token with the same audience value. The flawed cacheKeyBuilder produces an identical cache key, causing fast-jwt to return the cached admin token's claims instead of verifying the attacker's actual token. The application now processes the attacker's request with administrator identity and permissions, enabling privilege escalation, cross-tenant data access, or complete authorization bypass. No public exploit code exists, but exploitation requires only presenting tokens that trigger cache key collisions, which is trivial given the low attack complexity. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Apr 03, 2026
Cache key collisions in fast-jwt's custom cacheKeyBuilder implementations enable token confusion attacks, allowing remote attackers to impersonate users and escalate privileges without authentication. The vulnerability affects Node.js applications using fast-jwt with both caching enabled AND custom cache key builder functions that generate non-unique keys. No public exploit identified at time of analysis, though EPSS data unavailable and exploitation likelihood is high given the network-accessible attack vector (AV:N) and low complexity (AC:L). Applications using default caching behavior are NOT affected.
RemediationAI
Vendor-released patch available per GitHub advisory at https://github.com/nearform/fast-jwt/security/advisories/GHSA-rp9m-7r4c-75qg, though specific patched version number is not provided in available data. Immediate mitigation options include: remove custom cacheKeyBuilder implementations and rely on the secure default hash-based key generation; if custom builder is required, ensure uniqueness by including token-specific identifiers such as subject (sub), audience (aud), and issued-at timestamp (iat) in the cache key formula; disable caching entirely by setting cache to false in verifier configuration. Organizations should audit all fast-jwt deployments by searching codebases for cacheKeyBuilder function definitions and analyzing whether returned keys guarantee uniqueness across all possible token combinations. The advisory provides code examples distinguishing vulnerable patterns (grouping by audience or user type) from safe implementations (including sub, aud, and iat). Upgrade to patched version once available and verify configuration follows secure caching practices per advisory guidance.
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in npm
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Fast-jwt is an NPM package (pkg:npm/fast-jwt) providing JSON Web Token verification for Node.js applications. The vulnerability stems from CWE-345 (Insufficient Verification of Data Authenticity) in the token caching mechanism. When developers implement custom cacheKeyBuilder functions, the library uses the returned string as a cache lookup key for verified token data. If the key-building logic groups multiple distinct tokens under the same cache key-such as by audience alone rather than including unique identifiers like subject (sub) or issued-at (iat)-the cache returns cached claims from a different token. This breaks the fundamental security assumption that verified token data corresponds to the presented JWT, leading to identity confusion at the application layer. The default implementation uses a secure hash of the full token, making it collision-resistant, but the library permits developer override without validating uniqueness guarantees.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Primary rating from Vendor (https://github.com/nearform/fast-jwt) · only source for this CVE.
CVSS VectorVendor: https://github.com/nearform/fast-jwt
Lifecycle Timeline
2DescriptionCVE.org
Impact
Setting up a custom cacheKeyBuilder method which does not properly create unique keys for different tokens can lead to cache collisions. This could cause tokens to be mis-identified during the verification process leading to:
- Valid tokens returning claims from different valid tokens
- Users being mis-identified as other users based on the wrong token
This could result in:
- User impersonation - UserB receives UserA's identity and permissions
- Privilege escalation - Low-privilege users inherit admin-level access
- Cross-tenant data access - Users gain access to other tenants' resources
- Authorization bypass - Security decisions made on wrong user identity
Affected Configurations
This vulnerability ONLY affects applications that BOTH:
- Enable caching using the cache option
- Use custom cacheKeyBuilder functions that can produce collisions
VULNERABLE examples:
// Collision-prone: same audience = same cache key
cacheKeyBuilder: (token) => {
const { aud } = parseToken(token)
return `aud=${aud}`
}
// Collision-prone: grouping by user type
cacheKeyBuilder: (token) => {
const { aud } = parseToken(token)
return aud.includes('admin') ? 'admin-users' : 'regular-users'
}
// Collision-prone: tenant + service grouping
cacheKeyBuilder: (token) => {
const { iss, aud } = parseToken(token)
return `${iss}-${aud}`
}SAFE examples:
// Default hash-based (recommended)
createVerifier({ cache: true }) // Uses secure default
// Include unique user identifier
cacheKeyBuilder: (token) => {
const { sub, aud, iat } = parseToken(token)
return `${sub}-${aud}-${iat}`
}
// No caching (always safe)
createVerifier({ cache: false })Not Affected
- Applications using default caching
- Applications with caching disabled
Assessment Guide
To determine if a consumer application is affected:
- Check if caching is enabled: Look for cache: true or cache: <number> in verifier configuration
- Check for custom cache key builders: Look for cacheKeyBuilder function in configuration
- Analyze collision potential: Review if the application's cacheKeyBuilder can produce identical keys for different users/tokens
- If no custom cacheKeyBuilder: The project is NOT affected (default is safe)
Mitigations
While fast-jwt will look to include a fix for this in the next version, immediate mitigations include:
- Ensure uniqueness of keys produced in cacheKeyBuilder
- Remove custom cacheKeyBuilder method
- Disable caching
Executive ViewAI
CVE-2026-35039 affects Node.js applications using fast-jwt library with custom cache key builders, enabling attackers to forge authentication tokens and assume arbitrary user identities without credentials. Organizations running fast-jwt with non-default caching configurations face immediate risk of account takeover and privilege escalation; this requires urgent identification and patching of affected deployments.
Apply vendor patch. If patch deployment delayed: disable custom cacheKeyBuilder implementations and revert to default caching behavior; implement strict token expiration (short TTL); deploy additional authentication validation layer independent of cached tokens; monitor for anomalous authentication patterns and privilege escalation attempts.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Privilege escalation occurs when an attacker leverages flaws in access control mechanisms to gain permissions beyond what they were originally granted.
Exploit-DB