fast-jwt: Cache Confusion via cacheKeyBuilder Collisions Can Return Claims From a Different Token (Identity/Authorization Mixup)
_NOTE_: While the library exposes a mechanism which could introduce the vulnerability, this issue is created by developer-supplied code and not by the library itself. We will add a warning and some education for users around the possible issues however since the defaults work we will not be updating the library beyond that for this advisory.
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:
1. Enable caching using the cache option
2. 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 you're affected:
1. Check if caching is enabled: Look for cache: true or cache: <number> in verifier configuration
2. Check for custom cache key builders: Look for cacheKeyBuilder function in configuration
3. Analyze collision potential: Review if your cacheKeyBuilder can produce identical keys for different users/tokens
4. If no custom cacheKeyBuilder: You are NOT affected (default is safe)
Mitigations
Mitigations include:
- Ensure uniqueness of keys produced in cacheKeyBuilder
- Remove custom cacheKeyBuilder method
- Disable caching
fast-jwt allows enabling a verification cache through the cache option.
The cache key is derived from the token via cacheKeyBuilder.
When a custom cacheKeyBuilder produces collisions between different tokens, the verifier may return the cached payload of a previous token instead of validating and returning the payload of the current token.
This results in cross-token payload reuse and identity confusion.
Two distinct valid JWTs can be verified successfully but mapped to the same cached entry, causing the verifier to return claims belonging to a different token.
This affects authentication and authorization decisions when applications trust the returned payload.
Affected component
src/verifier.js
Relevant logic:
cache enabled via createCache
cache population via cacheSet
lookup based on cacheKeyBuilder(token)
cached payload returned without re-verification
Impact
Identity / authorization confusion via cache collision.
If two tokens generate the same cache key:
token A is verified → payload stored in cache
token B is verified → cache hit occurs
verifier returns payload from token A instead of B
Observed effect:
subject mismatch
claim mismatch
authorization decision performed on wrong identity
Potential real-world consequences:
user impersonation (logical)
privilege confusion
incorrect RBAC evaluation
gateway / middleware auth inconsistencies
This is especially dangerous when:
cache is enabled (recommended for performance)
custom cacheKeyBuilder is used
identity claims (sub / aud / iss) drive authorization
Root cause
The verifier assumes the cache key uniquely identifies the token and its claims.
However:
cacheKeyBuilder is user-controlled
collisions are not detected
cache entries store decoded payload
cached payload is returned without binding validation
This creates a trust boundary break between:
token → cache key → cached payload
Proof of concept
Environment:
fast-jwt: 6.1.0
Node.js: v24.13.1
PoC:
const { createSigner, createVerifier } = require('fast-jwt')
const sign = createSigner({ key: 'secret' })
// Two distinct tokens
const t1 = sign({ sub: 'userA', aud: 'a
