{"id":"CVE-2026-107721","aliases":["EUVD-2026-95345","GHSA-687g-22h4-j4w4"],"status":"published","title":"fast-jwt clockTolerance: Infinity silently bypasses both exp and nbf validation (and persists in the verifier cache)","description":"fast-jwt provides fast JSON Web Token (JWT) implementation. Prior to 6.3.0, fast-jwt createVerifier accepts Infinity for clockTolerance because its option validation checks type and negativity but not finiteness. In validateClaimDateValue, infinite positive and negative modifiers make exp and nbf comparisons always pass, allowing expired or not-yet-active tokens to be accepted. The verifier cache also derives infinite bounds, so entries created under this configuration can remain valid until eviction. Exploitation requires an application administrator or equivalent configuration path to set clockTolerance to Infinity. This issue is fixed in version 6.3.0.","severity":{"version":"3.1","score":5.9,"vector":"CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-12","score":0.00341,"percentile":0.28031,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-613","CWE-682"],"published":"2026-10-08T21:45:57Z","modified":"2026-10-28T02:30:31Z","fixes":[{"ecosystem":"npm","package":"fast-jwt","fixed_in":["6.3.0"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"npm","package":"fast-jwt","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"6.2.4"},{"fixed":"6.3.0"}]}]},{"source":"osv","ecosystem":"npm","package":"fast-jwt","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"6.3.0"}]}]}],"products":[{"vendor":"nearform","product":"fast-jwt"}],"references":[{"url":"https://github.com/nearform/fast-jwt/security/advisories/GHSA-687g-22h4-j4w4","tags":["x_refsource_CONFIRM","advisory","web"]},{"url":"https://github.com/nearform/fast-jwt/commit/c0fb5b88b4c88ff2bdd194ca2c713599ad9e38b6","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/nearform/fast-jwt/releases/tag/v6.3.0","tags":["x_refsource_MISC","web"]},{"url":"https://github.com/advisories/GHSA-687g-22h4-j4w4"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/107xxx/CVE-2026-107721.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-107721","tags":["advisory"]},{"url":"https://github.com/nearform/fast-jwt","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-107721","title":"fast-jwt clockTolerance: Infinity silently bypasses both exp and nbf validation (and persists in the verifier cache)","description":"fast-jwt provides fast JSON Web Token (JWT) implementation. Prior to 6.3.0, fast-jwt createVerifier accepts Infinity for clockTolerance because its option validation checks type and negativity but not finiteness. In validateClaimDateValue, infinite positive and negative modifiers make exp and nbf comparisons always pass, allowing expired or not-yet-active tokens to be accepted. The verifier cache also derives infinite bounds, so entries created under this configuration can remain valid until eviction. Exploitation requires an application administrator or equivalent configuration path to set clockTolerance to Infinity. This issue is fixed in version 6.3.0.","status":"published","published":"2026-10-08T21:45:57.545Z","modified":"2026-10-09T15:13:11.814Z","cvss":[{"version":"3.1","score":5.9,"vector":"CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N","level":"medium","assessor":"cna"}],"cwes":["CWE-613","CWE-682"],"updated_at":"2026-11-02T13:45:14.072357Z"}],"euvd":[{"id":"EUVD-2026-95345","description":"fast-jwt provides fast JSON Web Token (JWT) implementation. Prior to 6.3.0, fast-jwt createVerifier accepts Infinity for clockTolerance because its option validation checks type and negativity but not finiteness. In validateClaimDateValue, infinite positive and negative modifiers make exp and nbf comparisons always pass, allowing expired or not-yet-active tokens to be accepted. The verifier cache also derives infinite bounds, so entries created under this configuration can remain valid until eviction. Exploitation requires an application administrator or equivalent configuration path to set clockTolerance to Infinity. This issue is fixed in version 6.3.0.","status":"published","published":"2026-10-08T21:45:57Z","modified":"2026-10-09T15:13:11Z","cvss":[{"version":"3.1","score":5.9,"vector":"CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N","level":"medium"}],"updated_at":"2026-11-02T17:27:25.010362Z"}],"ghsa":[{"id":"GHSA-687g-22h4-j4w4","title":"fast-jwt clockTolerance: Infinity silently bypasses both exp and nbf validation (and persists in the verifier cache)","description":"## Summary\n\n`createVerifier({ clockTolerance: Infinity })` silently bypasses both `exp` (expiry) AND `nbf` (not-before) validation. Any expired or not-yet-active token is accepted as valid. The same primitive also corrupts the verifier's internal cache so cached entries inherit infinite validity — they remain valid past a later developer-removed Infinity config until LRU eviction.\n\n## Vulnerable code\n\n`src/verifier.js:531-533` — option validation only rejects negative values, not Infinity:\n\n```js\nif (clockTolerance \u0026\u0026 (typeof clockTolerance !== 'number' || clockTolerance \u003c 0)) {\n  throw new TokenError(TokenError.codes.invalidOption, 'The clockTolerance option must be a positive number.')\n}\n```\n\n`Infinity` passes (it's a number, not less than 0, truthy).\n\n`src/verifier.js:583-602` — clockTolerance flows into the date-claim validators:\n\n```js\nif (!ignoreNotBefore) {\n  validators.push({ ..., modifier: -clockTolerance })   // → -Infinity\n}\nif (!ignoreExpiration) {\n  validators.push({ ..., modifier: +clockTolerance })   // → Infinity\n}\n```\n\n`src/verifier.js:198-205` — applies modifier additively, producing always-pass comparisons:\n\n```js\nfunction validateClaimDateValue(value, modifier, now, greater, errorCode, errorVerb) {\n  const adjusted = value * 1000 + (modifier || 0)   // → ±Infinity\n  const valid = greater ? now \u003e= adjusted : now \u003c= adjusted   // → always true\n  ...\n}\n```\n\n## Empirical PoC\n\n```js\nconst { createSigner, createVerifier } = require('fast-jwt')\nconst secret = 'test-secret-with-enough-length-to-pass'\n\nconst sign = createSigner({ key: secret, algorithm: 'HS256' })\nconst expiredToken = sign({\n  sub: 'alice',\n  iat: Math.floor(Date.now()/1000) - 3600,\n  exp: Math.floor(Date.now()/1000) - 1800,  // expired 30 min ago\n})\n\nconst v1 = createVerifier({ key: secret })\ntry { v1(expiredToken) } catch (e) { console.log('baseline rejects:', e.message) }\n// → \"The token has expired at ...\"\n\nconst v2 = createVerifier({ key: secret, clockTolerance: Infinity })\nconsole.log('bypass:', v2(expiredToken))\n// → { sub: 'alice', iat: ..., exp: ... }  ← expired token accepted as valid\n\n// Not-yet-active token (nbf in 1 day) — same bypass\nconst futureToken = sign({\n  sub: 'bob',\n  iat: Math.floor(Date.now()/1000),\n  nbf: Math.floor(Date.now()/1000) + 86400,\n})\nconsole.log('bypass nbf:', v2(futureToken))\n// → { sub: 'bob', ... }  ← not-yet-active token accepted as valid\n```\n\nVerified against `fast-jwt@HEAD` on 2026-06-03 (commit pulled today).\n\n## Cache side-effect\n\nThe verifier's LRU cache uses `clockTolerance` to compute the cache entry's expiry window:\n\n`src/verifier.js:121-134`:\n```js\ncacheValue[1] = ... payload.nbf * 1000 - clockTolerance : 0                   // → -Infinity\ncacheValue[2] = payload.exp * 1000 + clockTolerance                            // → Infinity\nconst maxTTL = clockTimestamp + clockTolerance + cacheTTL                      // → Infinity\n```\n\nWith `clockTolerance: Infinity`, cache entries are stored with `[min=-Infinity, max=Infinity]`. The cache-hit check (`min === 0 || now \u003c min || now \u003c= max`) always passes for cached tokens.\n\n**Consequence**: a developer who briefly sets `clockTolerance: Infinity` (e.g., during debug) and then removes it will find that any verifications performed during the debug window remain cached as valid until LRU eviction (default 1000 entries).\n\n## Asymmetric hardening — the smoking-gun shape\n\n`src/signer.js:98, 104` CORRECTLY uses `Number.isFinite()` to reject Infinity for `expiresIn` and `notBefore`:\n\n```js\nexpiresIn != null \u0026\u0026 Number.isFinite(expiresIn)\n  ? Math.floor((iat + expiresIn) / 1000)\n  : ...\n```\n\nThe verifier's `clockTolerance` validation doesn't apply the same guard. The same `\u003c 0` check pattern is also applied to `clockTimestamp` (line 527-529) and `cacheTTL` (line 535-537) — both also accept `Infinity`.\n\nThis is the kind of asymmetry that often indicates a missed hardening pass: the sign-side was hardened against Infinity but the verify-side wasn't.\n\n## Threat model\n\nThe bug requires the developer to (mis)configure `clockTolerance: Infinity`. Realistic ways this happens:\n\n1. **Developer using Infinity as a sentinel** for \"disable expiry\": common JS idiom; many libraries accept Infinity as \"no limit.\" fast-jwt's signer treats Infinity as invalid (Number.isFinite false) but the verifier silently accepts it.\n2. **JSON / env-var misconfig**: config file or env var sets `clockTolerance` to `\"Infinity\"` (string); `Number(\"Infinity\") === Infinity`. Surprising via JSON.parse + Number cast or even `JSON.parse('{\"clockTolerance\": null}')` if the codec accepts null → Infinity.\n3. **Test config bleed**: integration tests use Infinity to make tokens never expire during long-running tests; the config bleeds into production.\n\nFor a JWT library, silently disabling token expiry on a \"looks like a non-negative number\" input is a security boundary failure.\n\n## Suggested fix\n\nSingle-line addition: use `Number.isFinite()` consistent with signer.js:\n\n```js\nif (clockTolerance \u0026\u0026 (typeof clockTolerance !== 'number' || !Number.isFinite(clockTolerance) || clockTolerance \u003c 0)) {\n  throw new TokenError(TokenError.codes.invalidOption, 'The clockTolerance option must be a finite, non-negative number.')\n}\n```\n\nSame fix for `clockTimestamp` (line 527-529) and `cacheTTL` (line 535-537) for consistency.\n\nOptional defense-in-depth: cap `clockTolerance` to a reasonable upper bound (e.g., 5 minutes = 300000 ms) with a `process.emitWarning` above that. Most legitimate use cases need \u003c60s tolerance.\n\n## Affected versions\n\nAll versions since clockTolerance was first introduced in PR #193 (v1.5.1). Current `main` HEAD on 2026-06-03 is affected.\n\n## Reporter\n\nAndrew Ridings (independent security researcher). Happy to coordinate disclosure timing and follow up with any clarifications. Email: ridingsa@gmail.com","status":"published","published":"2026-10-08T22:02:02Z","modified":"2026-10-08T22:02:03Z","cvss":[{"version":"3.1","score":5.9,"vector":"CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N","level":"medium"}],"cwes":["CWE-613","CWE-682"],"updated_at":"2026-11-02T14:41:30.097746Z"}],"nvd":[{"id":"CVE-2026-107721","description":"fast-jwt provides fast JSON Web Token (JWT) implementation. Prior to 6.3.0, fast-jwt createVerifier accepts Infinity for clockTolerance because its option validation checks type and negativity but not finiteness. In validateClaimDateValue, infinite positive and negative modifiers make exp and nbf comparisons always pass, allowing expired or not-yet-active tokens to be accepted. The verifier cache also derives infinite bounds, so entries created under this configuration can remain valid until eviction. Exploitation requires an application administrator or equivalent configuration path to set clockTolerance to Infinity. This issue is fixed in version 6.3.0.","status":"published","published":"2026-10-08T22:17:28.263Z","modified":"2026-10-09T16:17:23.59Z","cvss":[{"version":"3.1","score":5.9,"vector":"CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N","level":"medium","assessor":"secondary"}],"cwes":["CWE-613","CWE-682"],"updated_at":"2026-11-02T14:12:55.142936Z"}],"osv":[{"id":"CVE-2026-107721","title":"fast-jwt clockTolerance: Infinity silently bypasses both exp and nbf validation (and persists in the verifier cache)","description":"fast-jwt provides fast JSON Web Token (JWT) implementation. Prior to 6.3.0, fast-jwt createVerifier accepts Infinity for clockTolerance because its option validation checks type and negativity but not finiteness. In validateClaimDateValue, infinite positive and negative modifiers make exp and nbf comparisons always pass, allowing expired or not-yet-active tokens to be accepted. The verifier cache also derives infinite bounds, so entries created under this configuration can remain valid until eviction. Exploitation requires an application administrator or equivalent configuration path to set clockTolerance to Infinity. This issue is fixed in version 6.3.0.","status":"published","published":"2026-10-08T21:45:57.545Z","modified":"2026-10-28T02:30:31.489285936Z","cvss":[{"version":"3.1","score":5.9,"vector":"CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N","level":"medium"}],"cwes":["CWE-613","CWE-682"],"updated_at":"2026-11-02T15:44:54.933106Z"},{"id":"GHSA-687g-22h4-j4w4","title":"fast-jwt clockTolerance: Infinity silently bypasses both exp and nbf validation (and persists in the verifier cache)","description":"## Summary\n\n`createVerifier({ clockTolerance: Infinity })` silently bypasses both `exp` (expiry) AND `nbf` (not-before) validation. Any expired or not-yet-active token is accepted as valid. The same primitive also corrupts the verifier's internal cache so cached entries inherit infinite validity — they remain valid past a later developer-removed Infinity config until LRU eviction.\n\n## Vulnerable code\n\n`src/verifier.js:531-533` — option validation only rejects negative values, not Infinity:\n\n```js\nif (clockTolerance \u0026\u0026 (typeof clockTolerance !== 'number' || clockTolerance \u003c 0)) {\n  throw new TokenError(TokenError.codes.invalidOption, 'The clockTolerance option must be a positive number.')\n}\n```\n\n`Infinity` passes (it's a number, not less than 0, truthy).\n\n`src/verifier.js:583-602` — clockTolerance flows into the date-claim validators:\n\n```js\nif (!ignoreNotBefore) {\n  validators.push({ ..., modifier: -clockTolerance })   // → -Infinity\n}\nif (!ignoreExpiration) {\n  validators.push({ ..., modifier: +clockTolerance })   // → Infinity\n}\n```\n\n`src/verifier.js:198-205` — applies modifier additively, producing always-pass comparisons:\n\n```js\nfunction validateClaimDateValue(value, modifier, now, greater, errorCode, errorVerb) {\n  const adjusted = value * 1000 + (modifier || 0)   // → ±Infinity\n  const valid = greater ? now \u003e= adjusted : now \u003c= adjusted   // → always true\n  ...\n}\n```\n\n## Empirical PoC\n\n```js\nconst { createSigner, createVerifier } = require('fast-jwt')\nconst secret = 'test-secret-with-enough-length-to-pass'\n\nconst sign = createSigner({ key: secret, algorithm: 'HS256' })\nconst expiredToken = sign({\n  sub: 'alice',\n  iat: Math.floor(Date.now()/1000) - 3600,\n  exp: Math.floor(Date.now()/1000) - 1800,  // expired 30 min ago\n})\n\nconst v1 = createVerifier({ key: secret })\ntry { v1(expiredToken) } catch (e) { console.log('baseline rejects:', e.message) }\n// → \"The token has expired at ...\"\n\nconst v2 = createVerifier({ key: secret, clockTolerance: Infinity })\nconsole.log('bypass:', v2(expiredToken))\n// → { sub: 'alice', iat: ..., exp: ... }  ← expired token accepted as valid\n\n// Not-yet-active token (nbf in 1 day) — same bypass\nconst futureToken = sign({\n  sub: 'bob',\n  iat: Math.floor(Date.now()/1000),\n  nbf: Math.floor(Date.now()/1000) + 86400,\n})\nconsole.log('bypass nbf:', v2(futureToken))\n// → { sub: 'bob', ... }  ← not-yet-active token accepted as valid\n```\n\nVerified against `fast-jwt@HEAD` on 2026-06-03 (commit pulled today).\n\n## Cache side-effect\n\nThe verifier's LRU cache uses `clockTolerance` to compute the cache entry's expiry window:\n\n`src/verifier.js:121-134`:\n```js\ncacheValue[1] = ... payload.nbf * 1000 - clockTolerance : 0                   // → -Infinity\ncacheValue[2] = payload.exp * 1000 + clockTolerance                            // → Infinity\nconst maxTTL = clockTimestamp + clockTolerance + cacheTTL                      // → Infinity\n```\n\nWith `clockTolerance: Infinity`, cache entries are stored with `[min=-Infinity, max=Infinity]`. The cache-hit check (`min === 0 || now \u003c min || now \u003c= max`) always passes for cached tokens.\n\n**Consequence**: a developer who briefly sets `clockTolerance: Infinity` (e.g., during debug) and then removes it will find that any verifications performed during the debug window remain cached as valid until LRU eviction (default 1000 entries).\n\n## Asymmetric hardening — the smoking-gun shape\n\n`src/signer.js:98, 104` CORRECTLY uses `Number.isFinite()` to reject Infinity for `expiresIn` and `notBefore`:\n\n```js\nexpiresIn != null \u0026\u0026 Number.isFinite(expiresIn)\n  ? Math.floor((iat + expiresIn) / 1000)\n  : ...\n```\n\nThe verifier's `clockTolerance` validation doesn't apply the same guard. The same `\u003c 0` check pattern is also applied to `clockTimestamp` (line 527-529) and `cacheTTL` (line 535-537) — both also accept `Infinity`.\n\nThis is the kind of asymmetry that often indicates a missed hardening pass: the sign-side was hardened against Infinity but the verify-side wasn't.\n\n## Threat model\n\nThe bug requires the developer to (mis)configure `clockTolerance: Infinity`. Realistic ways this happens:\n\n1. **Developer using Infinity as a sentinel** for \"disable expiry\": common JS idiom; many libraries accept Infinity as \"no limit.\" fast-jwt's signer treats Infinity as invalid (Number.isFinite false) but the verifier silently accepts it.\n2. **JSON / env-var misconfig**: config file or env var sets `clockTolerance` to `\"Infinity\"` (string); `Number(\"Infinity\") === Infinity`. Surprising via JSON.parse + Number cast or even `JSON.parse('{\"clockTolerance\": null}')` if the codec accepts null → Infinity.\n3. **Test config bleed**: integration tests use Infinity to make tokens never expire during long-running tests; the config bleeds into production.\n\nFor a JWT library, silently disabling token expiry on a \"looks like a non-negative number\" input is a security boundary failure.\n\n## Suggested fix\n\nSingle-line addition: use `Number.isFinite()` consistent with signer.js:\n\n```js\nif (clockTolerance \u0026\u0026 (typeof clockTolerance !== 'number' || !Number.isFinite(clockTolerance) || clockTolerance \u003c 0)) {\n  throw new TokenError(TokenError.codes.invalidOption, 'The clockTolerance option must be a finite, non-negative number.')\n}\n```\n\nSame fix for `clockTimestamp` (line 527-529) and `cacheTTL` (line 535-537) for consistency.\n\nOptional defense-in-depth: cap `clockTolerance` to a reasonable upper bound (e.g., 5 minutes = 300000 ms) with a `process.emitWarning` above that. Most legitimate use cases need \u003c60s tolerance.\n\n## Affected versions\n\nAll versions since clockTolerance was first introduced in PR #193 (v1.5.1). Current `main` HEAD on 2026-06-03 is affected.\n\n## Reporter\n\nAndrew Ridings (independent security researcher). Happy to coordinate disclosure timing and follow up with any clarifications. Email: ridingsa@gmail.com","status":"published","published":"2026-10-08T22:02:02Z","modified":"2026-10-08T22:15:05.893519907Z","cvss":[{"version":"3.1","score":5.9,"vector":"CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N","level":"medium"}],"cwes":["CWE-613","CWE-682"],"updated_at":"2026-11-02T15:46:39.266402Z"}]}}