Mitigation Strategies

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.

Useful 0 Not Useful 0

Executive Summary

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.

Useful 0 Not Useful 0

Impact Analysis

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.

Useful 0 Not Useful 0

Detection Guidance

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.

Useful 0 Not Useful 0

Compliance Impact

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.

Useful 0 Not Useful 0