{
  "affected": [
    {
      "affectedData": [
        {
          "product": "fast-jwt",
          "vendor": "nearform",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 0.0.1, \u003c 6.2.0"
            }
          ]
        }
      ],
      "source": "security-advisories@github.com"
    }
  ],
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:a:nearform:fast-jwt:*:*:*:*:*:node.js:*:*",
              "matchCriteriaId": "9B0182D1-3EBD-449D-91F1-DE0E6B616CE4",
              "versionEndExcluding": "6.1.0",
              "versionStartIncluding": "0.1.0",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "fast-jwt provides fast JSON Web Token (JWT) implementation. From 0.0.1 to before 6.2.0, 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 and users being mis-identified as other users based on the wrong token. Version 6.2.0 contains a patch."
    }
  ],
  "id": "CVE-2026-35039",
  "lastModified": "2026-06-17T10:40:00.457",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "NETWORK",
          "availabilityImpact": "NONE",
          "baseScore": 9.1,
          "baseSeverity": "CRITICAL",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "privilegesRequired": "NONE",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
          "version": "3.1"
        },
        "exploitabilityScore": 3.9,
        "impactScore": 5.2,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2026-35039",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "yes"
            },
            {
              "technicalImpact": "total"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2026-04-07T14:25:32.378641Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2026-04-06T17:17:13.243",
  "references": [
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Patch"
      ],
      "url": "https://github.com/nearform/fast-jwt/commit/de121056c6415b58770c60640881eaec67ac4ceb"
    },
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Mitigation",
        "Vendor Advisory"
      ],
      "url": "https://github.com/nearform/fast-jwt/security/advisories/GHSA-rp9m-7r4c-75qg"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Analyzed",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-345"
        },
        {
          "lang": "en",
          "value": "CWE-706"
        },
        {
          "lang": "en",
          "value": "CWE-1289"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Secondary"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "fast-jwt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.0.1"
            },
            {
              "fixed": "6.2.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": "2026-04-06T17:17:13Z",
    "severity": "CRITICAL"
  },
  "details": "_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.\n\n## 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 you\u0027re 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 your cacheKeyBuilder can produce identical keys for different users/tokens\n4. If no custom cacheKeyBuilder: You are NOT affected (default is safe)\n\n## Mitigations\n\nMitigations include:\n\n- Ensure uniqueness of keys produced in cacheKeyBuilder\n- Remove custom cacheKeyBuilder method\n- Disable caching\n\n---\n\nfast-jwt allows enabling a verification cache through the cache option.\nThe cache key is derived from the token via cacheKeyBuilder.\n\nWhen 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.\n\nThis results in cross-token payload reuse and identity confusion.\n\nTwo 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.\n\nThis affects authentication and authorization decisions when applications trust the returned payload.\n\nAffected component\n\nsrc/verifier.js\n\nRelevant logic:\n\ncache enabled via createCache\n\ncache population via cacheSet\n\nlookup based on cacheKeyBuilder(token)\n\ncached payload returned without re-verification\n\nImpact\n\nIdentity / authorization confusion via cache collision.\n\nIf two tokens generate the same cache key:\n\ntoken A is verified \u2192 payload stored in cache\n\ntoken B is verified \u2192 cache hit occurs\n\nverifier returns payload from token A instead of B\n\nObserved effect:\n\nsubject mismatch\n\nclaim mismatch\n\nauthorization decision performed on wrong identity\n\nPotential real-world consequences:\n\nuser impersonation (logical)\n\nprivilege confusion\n\nincorrect RBAC evaluation\n\ngateway / middleware auth inconsistencies\n\nThis is especially dangerous when:\n\ncache is enabled (recommended for performance)\n\ncustom cacheKeyBuilder is used\n\nidentity claims (sub / aud / iss) drive authorization\n\nRoot cause\n\nThe verifier assumes the cache key uniquely identifies the token and its claims.\n\nHowever:\n\ncacheKeyBuilder is user-controlled\n\ncollisions are not detected\n\ncache entries store decoded payload\n\ncached payload is returned without binding validation\n\nThis creates a trust boundary break between:\n\ntoken \u2192 cache key \u2192 cached payload\n\nProof of concept\n\nEnvironment:\n\nfast-jwt: 6.1.0\n\nNode.js: v24.13.1\n\nPoC:\n\nconst { createSigner, createVerifier } = require(\u0027fast-jwt\u0027)\n\nconst sign = createSigner({ key: \u0027secret\u0027 })\n\n// Two distinct tokens\nconst t1 = sign({ sub: \u0027userA\u0027, aud: \u0027admin\u0027 })\nconst t2 = sign({ sub: \u0027userB\u0027, aud: \u0027admin\u0027 })\n\n// Deliberately unsafe cache key builder (collision)\nconst verify = createVerifier({\n  key: \u0027secret\u0027,\n  cache: true,\n  cacheKeyBuilder: () =\u003e \u0027static-key\u0027\n})\n\nconsole.log(\u0027verify t1\u0027)\nconst p1 = verify(t1)\nconsole.log(\u0027t1 PASS sub=\u0027, p1.sub)\n\nconsole.log(\u0027verify t2\u0027)\nconst p2 = verify(t2)\nconsole.log(\u0027t2 PASS sub=\u0027, p2.sub)\n\nconsole.log(\u0027verify t2 again\u0027)\nconst p3 = verify(t2)\nconsole.log(\u0027t2-again PASS sub=\u0027, p3.sub)\n\nconsole.log(\u0027verify t1 again\u0027)\nconst p4 = verify(t1)\nconsole.log(\u0027t1-again PASS sub=\u0027, p4.sub)\n\nObserved output:\n\nverify t1\nt1 PASS sub= userA\n\nverify t2\nt2 PASS sub= userA\n\nverify t2 again\nt2-again PASS sub= userA\n\nverify t1 again\nt1-again PASS sub= userA\n\nThe verifier returns payload from userA when verifying userB.\n\nExpected behavior\n\nCache must not allow returning claims from a different token.\n\nVerification must remain bound to the actual token being validated.\n\nEven if cache collisions occur, the verifier should:\n\nrevalidate signature\n\nre-decode payload\n\nor invalidate cache entry\n\nWhy this is not \u201cjust misuse\u201d\n\nThis is not merely a user mistake.\n\nReasons:\n\nfast-jwt explicitly exposes cacheKeyBuilder as an extension point.\n\nThe documentation suggests performance tuning via custom key builders.\n\nNo safeguards exist against collisions.\n\nNo verification binding is performed between:\n\ncached payload\n\noriginal token\n\nThe verifier trusts cache output as authoritative identity.\n\nThis creates a security-sensitive invariant:\n\n\"cache key uniqueness\"\n\nwhich is neither enforced nor validated.\n\nSecurity-critical libraries must assume extension hooks can be misused and implement defensive checks, especially when identity decisions are derived from cached values.\n\nSecurity classification\n\nlogical authorization flaw\n\ncache confusion vulnerability\n\nidentity boundary break\n\nClosest CWE:\n\nCWE-440 \u2014 Expected Behavior Violation\n\nSuggested fix (minimal and safe)\n\nBind cache entries to token integrity.\n\nOption A \u2014 safest:\n\nStore token hash along with payload and verify match before returning cache.\n\nConceptual patch:\n\nconst tokenHash = hashToken(token)\n\ncache.set(key, { tokenHash, payload })\n\n...\n\nconst entry = cache.get(key)\n\nif (entry \u0026\u0026 entry.tokenHash === hashToken(token)) {\n  return entry.payload\n}\n\nOption B \u2014 simpler:\n\nDisable cache usage when custom cacheKeyBuilder is provided.\n\nOption C \u2014 defensive:\n\nAlways re-validate signature when cache hit occurs.\n\nNotes\n\nDefault cacheKeyBuilder is safe (hash-based).\n\nIssue appears when custom builders are used \u2014 a documented and supported feature.\n\nImpact increases in:\n\nAPI gateways\n\nauth middleware\n\nRBAC layers relying on payload.sub / payload.aud\n\nThis vulnerability is independent from:\n\nRegExp statefulness issue\n\nReDoS claim validation issue\n\nIt is a separate flaw in cache design and trust model.\n\nPoC did on my computer:\n\u0027use strict\u0027\n\nconst fs = require(\u0027node:fs\u0027)\nconst path = require(\u0027node:path\u0027)\nconst { createSigner, createVerifier } = require(\u0027./src\u0027)\n\nfunction nowSec() {\n  return Math.floor(Date.now() / 1000)\n}\n\nconst sign = createSigner({ key: \u0027secret\u0027 })\nconst t1 = sign({ sub: \u0027userA\u0027, aud: \u0027admin\u0027, iat: nowSec() })\nconst t2 = sign({ sub: \u0027userB\u0027, aud: \u0027admin\u0027, iat: nowSec() })\n\nfunction badKeyBuilder() {\n  return \u0027aud=admin\u0027\n}\n\nconst verify = createVerifier({\n  key: \u0027secret\u0027,\n  cache: true,\n  cacheTTL: 60000,\n  cacheKeyBuilder: badKeyBuilder\n})\n\nfunction run(tok) {\n  try {\n    const out = verify(tok)\n    return { ok: true, sub: out.sub, aud: out.aud }\n  } catch (e) {\n    return { ok: false, code: e.code || String(e), message: e.message }\n  }\n}\n\nconst results = []\nresults.push({ step: \u0027verify(t1)\u0027, token: \u0027t1\u0027, result: run(t1) })\nresults.push({ step: \u0027verify(t2)\u0027, token: \u0027t2\u0027, result: run(t2) })\nresults.push({ step: \u0027verify(t2) again\u0027, token: \u0027t2\u0027, result: run(t2) })\nresults.push({ step: \u0027verify(t1) again\u0027, token: \u0027t1\u0027, result: run(t1) })\n\nconst evidence = {\n  title: \u0027fast-jwt cache confusion when cacheKeyBuilder collisions occur\u0027,\n  environment: {\n    node: process.version,\n    fastJwt: require(\u0027./package.json\u0027).version\n  },\n  config: {\n    cache: true,\n    cacheTTL: 60000,\n    cacheKeyBuilder: \"returns constant key \u0027aud=admin\u0027 (realistic collision pattern)\"\n  },\n  tokens: {\n    t1: { claims: { sub: \u0027userA\u0027, aud: \u0027admin\u0027 }, jwt: t1 },\n    t2: { claims: { sub: \u0027userB\u0027, aud: \u0027admin\u0027 }, jwt: t2 }\n  },\n  observed: results\n}\n\nconst outPath = path.join(process.cwd(), \u0027evidence-cache-keybuilder-confusion.json\u0027)\nfs.writeFileSync(outPath, JSON.stringify(evidence, null, 2))\nconsole.log(\u0027Wrote evidence to:\u0027, outPath)\n\nfor (const r of results) {\n  console.log(r.step, \u0027=\u003e\u0027, r.result.ok ? `PASS sub=${r.result.sub}` : `FAIL ${r.result.code}`)\n}\n\nOutput:\nPS C:\\Users\\Franciny Rojas\\Desktop\\crypto-research\\fast-jwt\u003e node poc_cache_keybuilder_confusion_evidence.js\nWrote evidence to: C:\\Users\\Franciny Rojas\\Desktop\\crypto-research\\fast-jwt\\evidence-cache-keybuilder-confusion.json\nverify(t1) =\u003e PASS sub=userA\nverify(t2) =\u003e PASS sub=userA\nverify(t2) again =\u003e PASS sub=userA\nverify(t1) again =\u003e PASS sub=userA\nPS C:\\Users\\Franciny Rojas\\Desktop\\crypto-research\\fast-jwt\u003e",
  "id": "GHSA-rp9m-7r4c-75qg",
  "modified": "2026-04-08T11:54:56Z",
  "published": "2026-04-03T04:07:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nearform/fast-jwt/security/advisories/GHSA-rp9m-7r4c-75qg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35039"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nearform/fast-jwt/commit/de121056c6415b58770c60640881eaec67ac4ceb"
    },
    {
      "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)"
}