Vulnerability-Lookup

GHSA-RP9M-7R4C-75QG

Vulnerability from github – Published: 2026-04-03 04:07 – Updated: 2026-04-08 11:54

Summary

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

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.

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:

Enable caching using the cache option
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 you're affected:

Check if caching is enabled: Look for cache: true or cache: in verifier configuration
Check for custom cache key builders: Look for cacheKeyBuilder function in configuration
Analyze collision potential: Review if your cacheKeyBuilder can produce identical keys for different users/tokens
If no custom cacheKeyBuilder: You are NOT affected (default is safe)

Mitigations

Mitigations include:

Ensure uniqueness of keys produced in cacheKeyBuilder
Remove custom cacheKeyBuilder method
Disable caching

fast-jwt allows enabling a verification cache through the cache option. The cache key is derived from the token via cacheKeyBuilder.

When 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.

This results in cross-token payload reuse and identity confusion.

Two 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.

This affects authentication and authorization decisions when applications trust the returned payload.

Affected component

src/verifier.js

Relevant logic:

cache enabled via createCache

cache population via cacheSet

lookup based on cacheKeyBuilder(token)

cached payload returned without re-verification

Impact

Identity / authorization confusion via cache collision.

If two tokens generate the same cache key:

token A is verified → payload stored in cache

token B is verified → cache hit occurs

verifier returns payload from token A instead of B

Observed effect:

subject mismatch

claim mismatch

authorization decision performed on wrong identity

Potential real-world consequences:

user impersonation (logical)

privilege confusion

incorrect RBAC evaluation

gateway / middleware auth inconsistencies

This is especially dangerous when:

cache is enabled (recommended for performance)

custom cacheKeyBuilder is used

identity claims (sub / aud / iss) drive authorization

Root cause

The verifier assumes the cache key uniquely identifies the token and its claims.

However:

cacheKeyBuilder is user-controlled

collisions are not detected

cache entries store decoded payload

cached payload is returned without binding validation

This creates a trust boundary break between:

token → cache key → cached payload

Proof of concept

Environment:

fast-jwt: 6.1.0

Node.js: v24.13.1

PoC:

const { createSigner, createVerifier } = require('fast-jwt')

const sign = createSigner({ key: 'secret' })

// Two distinct tokens const t1 = sign({ sub: 'userA', aud: 'admin' }) const t2 = sign({ sub: 'userB', aud: 'admin' })

// Deliberately unsafe cache key builder (collision) const verify = createVerifier({ key: 'secret', cache: true, cacheKeyBuilder: () => 'static-key' })

console.log('verify t1') const p1 = verify(t1) console.log('t1 PASS sub=', p1.sub)

console.log('verify t2') const p2 = verify(t2) console.log('t2 PASS sub=', p2.sub)

console.log('verify t2 again') const p3 = verify(t2) console.log('t2-again PASS sub=', p3.sub)

console.log('verify t1 again') const p4 = verify(t1) console.log('t1-again PASS sub=', p4.sub)

Observed output:

verify t1 t1 PASS sub= userA

verify t2 t2 PASS sub= userA

verify t2 again t2-again PASS sub= userA

verify t1 again t1-again PASS sub= userA

The verifier returns payload from userA when verifying userB.

Expected behavior

Cache must not allow returning claims from a different token.

Verification must remain bound to the actual token being validated.

Even if cache collisions occur, the verifier should:

revalidate signature

re-decode payload

or invalidate cache entry

Why this is not “just misuse”

This is not merely a user mistake.

Reasons:

fast-jwt explicitly exposes cacheKeyBuilder as an extension point.

The documentation suggests performance tuning via custom key builders.

No safeguards exist against collisions.

No verification binding is performed between:

cached payload

original token

The verifier trusts cache output as authoritative identity.

This creates a security-sensitive invariant:

"cache key uniqueness"

which is neither enforced nor validated.

Security-critical libraries must assume extension hooks can be misused and implement defensive checks, especially when identity decisions are derived from cached values.

Security classification

logical authorization flaw

cache confusion vulnerability

identity boundary break

Closest CWE:

CWE-440 — Expected Behavior Violation

Suggested fix (minimal and safe)

Bind cache entries to token integrity.

Option A — safest:

Store token hash along with payload and verify match before returning cache.

Conceptual patch:

const tokenHash = hashToken(token)

cache.set(key, { tokenHash, payload })

...

const entry = cache.get(key)

if (entry && entry.tokenHash === hashToken(token)) { return entry.payload }

Option B — simpler:

Disable cache usage when custom cacheKeyBuilder is provided.

Option C — defensive:

Always re-validate signature when cache hit occurs.

Notes

Default cacheKeyBuilder is safe (hash-based).

Issue appears when custom builders are used — a documented and supported feature.

Impact increases in:

API gateways

auth middleware

RBAC layers relying on payload.sub / payload.aud

This vulnerability is independent from:

RegExp statefulness issue

ReDoS claim validation issue

It is a separate flaw in cache design and trust model.

PoC did on my computer: 'use strict'

const fs = require('node:fs') const path = require('node:path') const { createSigner, createVerifier } = require('./src')

function nowSec() { return Math.floor(Date.now() / 1000) }

const sign = createSigner({ key: 'secret' }) const t1 = sign({ sub: 'userA', aud: 'admin', iat: nowSec() }) const t2 = sign({ sub: 'userB', aud: 'admin', iat: nowSec() })

function badKeyBuilder() { return 'aud=admin' }

const verify = createVerifier({ key: 'secret', cache: true, cacheTTL: 60000, cacheKeyBuilder: badKeyBuilder })

function run(tok) { try { const out = verify(tok) return { ok: true, sub: out.sub, aud: out.aud } } catch (e) { return { ok: false, code: e.code || String(e), message: e.message } } }

const results = [] results.push({ step: 'verify(t1)', token: 't1', result: run(t1) }) results.push({ step: 'verify(t2)', token: 't2', result: run(t2) }) results.push({ step: 'verify(t2) again', token: 't2', result: run(t2) }) results.push({ step: 'verify(t1) again', token: 't1', result: run(t1) })

const evidence = { title: 'fast-jwt cache confusion when cacheKeyBuilder collisions occur', environment: { node: process.version, fastJwt: require('./package.json').version }, config: { cache: true, cacheTTL: 60000, cacheKeyBuilder: "returns constant key 'aud=admin' (realistic collision pattern)" }, tokens: { t1: { claims: { sub: 'userA', aud: 'admin' }, jwt: t1 }, t2: { claims: { sub: 'userB', aud: 'admin' }, jwt: t2 } }, observed: results }

const outPath = path.join(process.cwd(), 'evidence-cache-keybuilder-confusion.json') fs.writeFileSync(outPath, JSON.stringify(evidence, null, 2)) console.log('Wrote evidence to:', outPath)

for (const r of results) { console.log(r.step, '=>', r.result.ok ? PASS sub=${r.result.sub} : FAIL ${r.result.code}) }

Output: PS C:\Users\Franciny Rojas\Desktop\crypto-research\fast-jwt> node poc_cache_keybuilder_confusion_evidence.js Wrote evidence to: C:\Users\Franciny Rojas\Desktop\crypto-research\fast-jwt\evidence-cache-keybuilder-confusion.json verify(t1) => PASS sub=userA verify(t2) => PASS sub=userA verify(t2) again => PASS sub=userA verify(t1) again => PASS sub=userA PS C:\Users\Franciny Rojas\Desktop\crypto-research\fast-jwt>

Severity ?

9.1 (Critical)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "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)"
}

CVE-2026-35039 (GCVE-0-2026-35039)

Vulnerability from cvelistv5 – Published: 2026-04-06 16:59 – Updated: 2026-05-13 15:12

Title

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

Summary

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.

Severity ?

9.1 (Critical)


                        
                          CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

CWE

CWE-345 - Insufficient Verification of Data Authenticity
CWE-706 - Use of Incorrectly-Resolved Name or Reference
CWE-1289 - Improper Validation of Unsafe Equivalence in Input

Assigner

GitHub_M

References

2 references

URL	Tags
https://github.com/nearform/fast-jwt/security/adv…	x_refsource_CONFIRM
https://github.com/nearform/fast-jwt/commit/de121…	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version
nearform	fast-jwt	Affected: >= 0.0.1, < 6.2.0

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-35039",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-04-07T14:25:32.378641Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-05-13T15:12:43.989Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "fast-jwt",
          "vendor": "nearform",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 0.0.1, \u003c 6.2.0"
            }
          ]
        }
      ],
      "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."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "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"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-345",
              "description": "CWE-345: Insufficient Verification of Data Authenticity",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-706",
              "description": "CWE-706: Use of Incorrectly-Resolved Name or Reference",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-1289",
              "description": "CWE-1289: Improper Validation of Unsafe Equivalence in Input",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-04-08T11:54:39.776Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/nearform/fast-jwt/security/advisories/GHSA-rp9m-7r4c-75qg",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/nearform/fast-jwt/security/advisories/GHSA-rp9m-7r4c-75qg"
        },
        {
          "name": "https://github.com/nearform/fast-jwt/commit/de121056c6415b58770c60640881eaec67ac4ceb",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/nearform/fast-jwt/commit/de121056c6415b58770c60640881eaec67ac4ceb"
        }
      ],
      "source": {
        "advisory": "GHSA-rp9m-7r4c-75qg",
        "discovery": "UNKNOWN"
      },
      "title": "fast-jwt Affected by Cache Confusion via cacheKeyBuilder Collisions Can Return Claims From a Different Token (Identity/Authorization Mixup)"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-35039",
    "datePublished": "2026-04-06T16:59:43.124Z",
    "dateReserved": "2026-03-31T21:06:06.428Z",
    "dateUpdated": "2026-05-13T15:12:43.989Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

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.

Detection rules are retrieved from Rulezet.

Action not permitted

GHSA-RP9M-7R4C-75QG

Impact

Affected Configurations

Not Affected

Assessment Guide

Mitigations

CVE-2026-35039 (GCVE-0-2026-35039)

Tags

Sightings

Nomenclature