fast-jwt: Cache Confusion via cacheKeyBuilder Collisions Can Return Claims From a Different Token (Identity/Authorization Mixup)

## 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 a consumer application is 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 the application's cacheKeyBuilder can produce identical keys for different users/tokens 4. 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