GHSA-X937-HJ6V-793P
Vulnerability from github – Published: 2026-10-08 22:10 – Updated: 2026-10-08 22:10Summary
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:
- Verify signature.
- Check exp against the current time.
- 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:
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:
{
"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:
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:
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
expbut noiat. - 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
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.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.3.3"
},
"package": {
"ecosystem": "npm",
"name": "fast-jwt"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.3.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-107719"
],
"database_specific": {
"cwe_ids": [
"CWE-613"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-08T22:10:35Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n`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.\n\n### Details\nThe bug is an expiration-check bypass caused by caching.\n\nNormally, verification works like this:\n\n 1. Verify signature.\n 2. Check exp against the current time.\n 3. Return the JWT claims.\n\nWith caching enabled, `fast-jwt` saves successful verification results so it can avoid repeating crypto work for the same token.\n\nThe intended invariant is:\n\n \u003e A cached token must stop being accepted at the same time as a non-cached token.\n\nBut the cache computes its expiration incorrectly.\n\nIn `fast-jwt/src/verifier.js:127`, the code first checks whether the payload has an iat (\u201cissued at\u201d) claim:\n\n```js\nconst hasIat = payload \u0026\u0026 typeof payload.iat === \u0027number\u0027\n\nif (hasIat) {\n if (!ignoreExpiration \u0026\u0026 typeof payload.exp === \u0027number\u0027) {\n cacheValue[2] = payload.exp * 1000 + clockTolerance\n }\n}\n```\n\nThat means `exp` is considered only when `iat` exists.\n\nHowever, `iat` is optional in JWT. A perfectly valid JWT may contain:\n\n```js\n{\n \"sub\": \"alice\",\n \"exp\": 1700000001\n}\n```\nwith no iat.\n\nFor that token, the expiration-based cache deadline is never set. The code falls back to the generic cache TTL\u201410 minutes by default:\n\n```js\nconst maxTTL = clockTimestamp + clockTolerance + cacheTTL\ncacheValue[2] = cacheValue[2] === 0 ? maxTTL : Math.min(cacheValue[2], maxTTL)\n```\n\nLater, cache lookup happens before decoding and expiration validation:\n\n```js\nconst [value, min, max] = cache.get(cacheKeyBuilder(token)) || [undefined, 0, 0]\n\nif (typeof value !== \u0027undefined\u0027 \u0026\u0026 (max === 0 || now \u003c= max)) {\n return handleCachedResult(value, callback, promise)\n}\n```\n\nSo the timeline is:\n\n```\n 12:00:00 Token has exp = 12:00:01, no iat.\n 12:00:00 Server verifies it successfully and caches its claims.\n 12:00:01 Token expires.\n 12:00:02 Attacker replays the identical token.\n 12:00:02 Cache hit returns old claims; exp is never rechecked.\n 12:10:00 Cache TTL finally ends; normal expiration rejection resumes.\n```\n\nAn 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:\n\n - The application enables `cache`.\n - The JWT has `exp` but no `iat`.\n - The token was cached before expiry.\n - It is replayed before the cache entry expires.\n\nImpact 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.\n\nThe 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.\n\n### PoC\n```js\nconst assert = require(\u0027node:assert/strict\u0027)\nconst { createSigner, createVerifier } = require(\u0027fast-jwt\u0027)\n\nconst key = \u0027audit-only-secret\u0027\nconst originalNow = Date.now\n\ntry {\n const initialNow = 1_700_000_000_000\n const exp = Math.floor(initialNow / 1000) + 1 // expires one second later\n\n // noTimestamp intentionally omits iat, while exp is retained.\n const sign = createSigner({\n key,\n algorithm: \u0027HS256\u0027,\n noTimestamp: true\n })\n const token = sign({ sub: \u0027alice\u0027, exp })\n\n const verify = createVerifier({\n key,\n algorithms: [\u0027HS256\u0027],\n cache: true,\n cacheTTL: 60_000\n })\n\n Date.now = () =\u003e initialNow\n assert.equal(verify(token).sub, \u0027alice\u0027) // Valid; stores cache entry.\n\n Date.now = () =\u003e exp * 1000 + 1\n assert.equal(verify(token).sub, \u0027alice\u0027) // BUG: should throw FAST_JWT_EXPIRED.\n\n console.log(\u0027VULNERABLE: expired exp-without-iat token served from cache\u0027)\n} finally {\n Date.now = originalNow\n}\n```\n\n### Impact\nThis is an authentication/session-expiration bypass caused by incorrect cache validation.\nThe following are impacted:\n - Applications using the affected fast-jwt code with cache: true.\n - Applications that rely on JWT exp to end sessions or limit bearer-token lifetime.\n - Tokens with exp but no iat, after they were successfully verified and cached.",
"id": "GHSA-x937-hj6v-793p",
"modified": "2026-10-08T22:10:35Z",
"published": "2026-10-08T22:10:35Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nearform/fast-jwt/security/advisories/GHSA-x937-hj6v-793p"
},
{
"type": "WEB",
"url": "https://github.com/nearform/fast-jwt/commit/fc1ddbbe5ce38066ba2cea0b0ce0233932757167"
},
{
"type": "PACKAGE",
"url": "https://github.com/nearform/fast-jwt"
},
{
"type": "WEB",
"url": "https://github.com/nearform/fast-jwt/releases/tag/v6.3.4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "fast-jwt: Verifier cache accepts expired JWTs without iat."
}
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.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.