CVE-2026-107719

CVE-2026-107719 is a medium-severity security vulnerability in fast-jwt (npm), affecting versions <= 6.3.3. It is fixed in 6.3.4.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

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

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:

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

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.

CVE-2026-107719 has a CVSS score of 4.2 (Medium). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (6.3.4); upgrading removes the vulnerable code path.

Affected versions

fast-jwt (<= 6.3.3)

Security releases

fast-jwt → 6.3.4 (npm)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

Upgrade fast-jwt to 6.3.4 or later to resolve this vulnerability.

Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.

Frequently Asked Questions

  1. What is CVE-2026-107719? CVE-2026-107719 is a medium-severity security vulnerability in fast-jwt (npm), affecting versions <= 6.3.3. It is fixed in 6.3.4.
  2. How severe is CVE-2026-107719? CVE-2026-107719 has a CVSS score of 4.2 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
  3. Which versions of fast-jwt are affected by CVE-2026-107719? fast-jwt (npm) versions <= 6.3.3 is affected.
  4. Is there a fix for CVE-2026-107719? Yes. CVE-2026-107719 is fixed in 6.3.4. Upgrade to this version or later.
  5. Is CVE-2026-107719 exploitable, and should I be worried? Whether CVE-2026-107719 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  6. What actually determines whether CVE-2026-107719 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  7. How do I fix CVE-2026-107719? Upgrade fast-jwt to 6.3.4 or later.

Other vulnerabilities in fast-jwt

Stop the waste.
Protect your environment with Kodem.