GHSA-RP9M-7R4C-75QG

Vulnerability from github – Published: 2026-04-03 04:07 – Updated: 2026-04-03 04:07
VLAI?
Summary
fast-jwt: Cache Confusion via cacheKeyBuilder Collisions Can Return Claims From a Different Token (Identity/Authorization Mixup)
Details

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: 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
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "fast-jwt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.0.1"
            },
            {
              "fixed": "6.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-35039"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1289",
      "CWE-345",
      "CWE-706"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-03T04:07:09Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "## Impact\n\nSetting 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:\n\n- Valid tokens returning claims from different valid tokens\n- Users being mis-identified as other users based on the wrong token\n\nThis could result in:\n- User impersonation - UserB receives UserA\u0027s identity and permissions\n- Privilege escalation - Low-privilege users inherit admin-level access\n- Cross-tenant data access - Users gain access to other tenants\u0027 resources\n- Authorization bypass - Security decisions made on wrong user identity\n\n## Affected Configurations\n\nThis vulnerability ONLY affects applications that BOTH:\n\n1. Enable caching using the cache option\n2. Use custom cacheKeyBuilder functions that can produce collisions\n\nVULNERABLE examples:\n```\n// Collision-prone: same audience = same cache key\ncacheKeyBuilder: (token) =\u003e {\n  const { aud } = parseToken(token)\n  return `aud=${aud}`\n}\n\n// Collision-prone: grouping by user type\ncacheKeyBuilder: (token) =\u003e {\n  const { aud } = parseToken(token)\n  return aud.includes(\u0027admin\u0027) ? \u0027admin-users\u0027 : \u0027regular-users\u0027\n}\n\n// Collision-prone: tenant + service grouping\ncacheKeyBuilder: (token) =\u003e {\n  const { iss, aud } = parseToken(token)\n  return `${iss}-${aud}`\n}\n```\n\nSAFE examples:\n```\n// Default hash-based (recommended)\ncreateVerifier({ cache: true })  // Uses secure default\n\n// Include unique user identifier\ncacheKeyBuilder: (token) =\u003e {\n  const { sub, aud, iat } = parseToken(token)\n  return `${sub}-${aud}-${iat}`\n}\n\n// No caching (always safe)\ncreateVerifier({ cache: false })\n```\n### Not Affected\n\n- Applications using **default caching**\n- Applications with **caching disabled**\n \n## Assessment Guide\n\nTo determine if a consumer application is affected:\n\n1. Check if caching is enabled: Look for cache: true or cache: \u003cnumber\u003e in verifier configuration\n2. Check for custom cache key builders: Look for cacheKeyBuilder function in configuration\n3. Analyze collision potential: Review if the application\u0027s cacheKeyBuilder can produce identical keys for different users/tokens\n4. If no custom cacheKeyBuilder: The project is NOT affected (default is safe)\n\n## Mitigations\n\nWhile fast-jwt will look to include a fix for this in the next version, immediate mitigations include:\n\n- Ensure uniqueness of keys produced in cacheKeyBuilder\n- Remove custom cacheKeyBuilder method\n- Disable caching",
  "id": "GHSA-rp9m-7r4c-75qg",
  "modified": "2026-04-03T04:07:09Z",
  "published": "2026-04-03T04:07:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nearform/fast-jwt/security/advisories/GHSA-rp9m-7r4c-75qg"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nearform/fast-jwt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "fast-jwt: Cache Confusion via cacheKeyBuilder Collisions Can Return Claims From a Different Token (Identity/Authorization Mixup)"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…