PT-2026-30016 · Npm · Fast-Jwt
Published
2026-04-03
·
Updated
2026-04-03
·
CVE-2026-35039
CVSS v3.1
9.1
Critical
| AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N |
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: 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
Fix
Insufficient Verification of Data Authenticity
Found an issue in the description? Have something to add? Feel free to write us 👾
Related Identifiers
Affected Products
Fast-Jwt