CVE-2026-35039
Cache Key Collision in fast-jwt Causes Token Misidentification
Publication date: 2026-04-06
Last updated on: 2026-04-22
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| nearform | fast-jwt | From 0.1.0 (inc) to 6.1.0 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-1289 | The product receives an input value that is used as a resource identifier or other type of reference, but it does not validate or incorrectly validates that the input is equivalent to a potentially-unsafe value. |
| CWE-345 | The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data. |
| CWE-706 | The product uses a name or reference to access a resource, but the name/reference resolves to a resource that is outside of the intended control sphere. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-35039 is a critical vulnerability in the fast-jwt package versions from 0.0.1 to before 6.1.0 related to how token verification caching is handled.
When a custom cacheKeyBuilder function is used that does not create unique cache keys for different JSON Web Tokens (JWTs), cache collisions can occur. This means that different valid tokens might produce the same cache key.
As a result, during token verification, the system may return cached claims from a different token than the one being verified, causing users to be mis-identified as other users.
The root cause is that the verifier trusts the cache key as a unique identifier for the token and its claims, but the user-controlled cacheKeyBuilder can produce collisions, breaking the trust boundary between token, cache key, and cached payload.
How can this vulnerability impact me? :
This vulnerability can have severe security impacts including:
- User impersonation, where a user may receive another user's identity and permissions.
- Privilege escalation, allowing low-privilege users to inherit admin-level access.
- Cross-tenant data access, enabling users to access resources belonging to other tenants.
- Authorization bypass, where security decisions are made based on incorrect user identity.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability arises when a custom cacheKeyBuilder function is used with caching enabled in fast-jwt, causing cache collisions that lead to token mis-identification.
To detect this vulnerability, you should review your application's fast-jwt configuration to check if caching is enabled (cache: true) and if a custom cacheKeyBuilder function is used.
Specifically, look for cacheKeyBuilder implementations that do not produce unique keys per token, such as those returning keys based only on token audience or user groups.
Since this is a logical flaw in token verification caching, detection involves code inspection rather than network commands.
No specific network or system commands are provided in the resources to detect this vulnerability automatically.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability can lead to user impersonation, privilege escalation, cross-tenant data access, and authorization bypass due to cache collisions in token verification. Such issues can cause unauthorized access to sensitive personal or protected health information.
As a result, organizations using affected versions of fast-jwt with vulnerable configurations may fail to adequately protect user identities and data confidentiality, potentially violating compliance requirements under standards like GDPR and HIPAA that mandate strict access controls and data protection.
Specifically, the risk of cross-tenant data access and incorrect authorization decisions could lead to unauthorized disclosure or misuse of personal data, which is a direct compliance concern under these regulations.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include disabling caching in fast-jwt by setting cache: false if you are using a custom cacheKeyBuilder that cannot guarantee unique keys.
Alternatively, use the default hash-based cache key builder provided by fast-jwt (e.g., createVerifier({ cache: true })) which ensures unique cache keys.
If you must use a custom cacheKeyBuilder, ensure it includes unique user identifiers such as 'sub' (subject), 'aud' (audience), and 'iat' (issued at) claims to avoid collisions.
Additionally, implement verification of token integrity by storing and checking a hash of the token alongside cached payloads before returning cached data.
Always re-validate the token signature on cache hits to prevent authorization bypass.