fast-jwt: Verifier cache accepts expired JWTs without iat.

CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.

No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.

fast-jwt provides fast JSON Web Token (JWT) implementation. Prior to 6.3.4, the fast-jwt createVerifier cache can continue accepting a previously valid, signed JWT after its exp time when caching is enabled and the token has exp but no iat. In src/verifier.js, cacheSet derives the exp cache deadline only when iat is present, so the cache falls back to cacheTTL, and a later cache hit returns the saved payload before verifyToken rechecks expiration. An attacker who can replay the same cached bearer token can extend access until the cache entry expires, but cannot forge a token through this issue. This issue is fixed in version 6.3.4.

Source published

8 Oct 2026 21:41:55 UTC

Source modified

9 Oct 2026 15:48:26 UTC

Observed here

23 Oct 2026 15:48:27 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.

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

fast-jwt provides fast JSON Web Token (JWT) implementation. Prior to 6.3.4, the fast-jwt createVerifier cache can continue accepting a previously valid, signed JWT after its exp time when caching is enabled and the token has exp but no iat. In src/verifier.js, cacheSet derives the exp cache deadline only when iat is present, so the cache falls back to cacheTTL, and a later cache hit returns the saved payload before verifyToken rechecks expiration. An attacker who can replay the same cached bearer token can extend access until the cache entry expires, but cannot forge a token through this issue. This issue is fixed in version 6.3.4.

Source published

Oct 8, 2026, 9:41:55 PM (timezone not stated)

Source modified

Oct 9, 2026, 3:48:26 PM (timezone not stated)

Observed here

9 Nov 2026 05:08:03 UTC

Source terms

ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: euvd · ENISA EUVD · source terms and attribution apply. Source text is retained; field grouping and change labels are provided by ChangeIntel.

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

fast-jwt provides fast JSON Web Token (JWT) implementation. Prior to 6.3.4, the fast-jwt createVerifier cache can continue accepting a previously valid, signed JWT after its exp time when caching is enabled and the token has exp but no iat. In src/verifier.js, cacheSet derives the exp cache deadline only when iat is present, so the cache falls back to cacheTTL, and a later cache hit returns the saved payload before verifyToken rechecks expiration. An attacker who can replay the same cached bearer token can extend access until the cache entry expires, but cannot forge a token through this issue. This issue is fixed in version 6.3.4.

Source published

8 Oct 2026 22:17:27 UTC

Source modified

9 Oct 2026 16:17:23 UTC

Observed here

25 Oct 2026 05:17:13 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · [email protected] · Secondary · 4.2 CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N

### Summary `cacheSet` only derives its `exp` cache deadline inside `hasIat` (`src/verifier.js:127-140`). JWT `iat` is optional. For a valid token with `exp` but no `iat`, `cacheSet` substitutes `clockTimestamp + clockTolerance + cacheTTL` (`src/verifier.js:142-146`). Later, the cache path returns the saved payload before decoding or invoking `verifyToken` (`src/verifier.js:372-388`). Since expiration validation is in `verifyToken`, the expired token remains accepted until the cache deadline. ### Details The bug is an expiration-check bypass caused by caching. Normally, verification works like this: 1. Verify signature. 2. Check exp against the current time. 3. Return the JWT claims. With caching enabled, `fast-jwt` saves successful verification results so it can avoid repeating crypto work for the same token. The intended invariant is: > A cached token must stop being accepted at the same time as a non-cached token. But the cache computes its expiration incorrectly. In `fast-jwt/src/verifier.js:127`, the code first checks whether the payload has an iat (“issued at”) claim: ```js const hasIat = payload && typeof payload.iat === 'number' if (hasIat) { if (!ignoreExpiration && typeof payload.exp === 'number') { cacheValue[2] = payload.exp * 1000 + clockTolerance } } ``` That means `exp` is considered only when `iat` exists. However, `iat` is optional in JWT. A perfectly valid JWT may contain: ```js { "sub": "alice", "exp": 1700000001 } ``` with no iat. For that token, the expiration-based cache deadline is never set. The code falls back to the generic cache TTL—10 minutes by default: ```js const maxTTL = clockTimestamp + clockTolerance + cacheTTL cacheValue[2] = cacheValue[2] === 0 ? maxTTL : Math.min(cacheValue[2], maxTTL) ``` Later, cache lookup happens before decoding and expiration validation: ```js const [value, min, max] = cache.get(cacheKeyBuilder(token)) || [undefined, 0, 0] if (typeof value !== 'undefined' && (max === 0 || now <= max)) { return handleCachedResult(value, callback, promise) } ``` So the timeline is: ``` 12:00:00 Token has exp = 12:00:01, no iat. 12:00:00 Server verifies it successfully and caches its claims. 12:00:01 Token expires. 12:00:02 Attacker replays the identical token. 12:00:02 Cache hit returns old claims; exp is never rechecked. 12:10:00 Cache TTL finally ends; normal expiration rejection resumes. ``` An attacker cannot forge a token through this issue. They need a valid token first; typically their own, or a stolen bearer token. But they can keep using it after its intended expiration if all of these are true: - The application enables `cache`. - The JWT has `exp` but no `iat`. - The token was cached before expiry. - It is replayed before the cache entry expires. Impact depends on the application. For a short-lived access token, it can extend access by up to the configured `cacheTTL` of 10 minutes by default, or more if the application configured it that way. This undermines expiry as an authentication/session boundary. The minimal repair is to calculate the cache deadline from `exp` independently of `iat`. `iat` should only matter for `maxAge`, because max age is inherently defined relative to issuance time. ### PoC ```js const assert = require('node:assert/strict') const { createSigner, createVerifier } = require('fast-jwt') const key = 'audit-only-secret' const originalNow = Date.now try { const initialNow = 1_700_000_000_000 const exp = Math.floor(initialNow / 1000) + 1 // expires one second later // noTimestamp intentionally omits iat, while exp is retained. const sign = createSigner({ key, algorithm: 'HS256', noTimestamp: true }) const token = sign({ sub: 'alice', exp }) const verify = createVerifier({ key, algorithms: ['HS256'], cache: true, cacheTTL: 60_000 }) Date.now = () => initialNow assert.equal(verify(token).sub, 'alice') // Valid; stores cache entry. Date.now = () => exp * 1000 + 1 assert.equal(verify(token).sub, 'alice') // BUG: should throw FAST_JWT_EXPIRED. console.log('VULNERABLE: expired exp-without-iat token served from cache') } finally { Date.now = originalNow } ``` ### Impact This is an authentication/session-expiration bypass caused by incorrect cache validation. The following are impacted: - Applications using the affected fast-jwt code with cache: true. - Applications that rely on JWT exp to end sessions or limit bearer-token lifetime. - Tokens with exp but no iat, after they were successfully verified and cached.

Source published

8 Oct 2026 22:10:35 UTC

Source modified

8 Oct 2026 22:30:41 UTC

Observed here

24 Oct 2026 13:17:17 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

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

Publisher rating · MODERATE