CVE-2026-107719: fast-jwt Authentication Bypass Vulnerability

CVE-2026-107719 Overview

CVE-2026-107719 affects fast-jwt, a widely used JSON Web Token (JWT) implementation for Node.js. The vulnerability resides in the createVerifier cache logic within src/verifier.js. When caching is enabled and a token contains an exp claim but no iat claim, the cache deadline falls back to cacheTTL instead of the token's expiration. Subsequent cache hits return the saved payload before verifyToken re-validates expiration. An attacker who can replay a previously valid bearer token can extend access beyond its intended lifetime, up to the cache entry's TTL. This issue is fixed in fast-jwt version 6.3.4 and is tracked as [CWE-613] (Insufficient Session Expiration).

Critical Impact

Attackers replaying a captured, previously valid JWT can bypass expiration enforcement and retain authenticated access until the cache entry expires.

Affected Products

• fast-jwt versions prior to 6.3.4
• Node.js services using createVerifier with caching enabled
• Applications issuing JWTs with exp but no iat claim

Discovery Timeline

• 2026-10-08 - CVE-2026-107719 published to NVD
• 2026-10-09 - Last updated in NVD database

Technical Details for CVE-2026-107719

Vulnerability Analysis

The flaw is a session expiration weakness in fast-jwt's verifier cache. createVerifier caches verified JWT payloads to avoid repeated cryptographic validation. The cache entry stores a validity window used on cache hits to short-circuit re-verification. When the cached deadline is computed incorrectly, expired tokens can pass as valid on subsequent requests.

An attacker needs an already-valid signed JWT and the ability to replay it to the target service. Token forgery is not possible through this issue, and the signing key remains protected. The impact is bounded by the configured cacheTTL, after which the stale entry is evicted and normal expiration enforcement resumes.

Root Cause

In src/verifier.js, the cacheSet function only populated the expiration slot of the cache value when the payload contained an iat claim. For tokens with exp but no iat, the expiration bound was never set, so the entry defaulted to the broader cacheTTL window. On a cache hit, the saved payload was returned before verifyToken had a chance to re-check exp, allowing an expired token to be accepted.

Attack Vector

Exploitation requires network access to an endpoint protected by fast-jwt with caching enabled, plus possession of a signed JWT that lacks iat but includes exp. The attacker replays the token after its exp has passed. If the entry remains in the verifier cache, the request is honored. Attack complexity is elevated because the attacker must capture a valid token and the service configuration must match the vulnerable pattern.

// Patch excerpt from src/verifier.js
-  const hasIat = payload && typeof payload.iat === 'number'
+  // Each bound mirrors its validator in createVerifier
+  cacheValue[1] = !ignoreNotBefore && typeof payload.nbf === 'number' ? payload.nbf * 1000 - clockTolerance : 0

-  // Add time range of the token
-  if (hasIat) {
-    cacheValue[1] = !ignoreNotBefore && typeof payload.nbf === 'number' ? payload.nbf * 1000 - clockTolerance : 0
+  let expiresAt = clockTimestamp + clockTolerance + cacheTTL

-    if (!ignoreExpiration) {
-      if (typeof payload.exp === 'number') {
-        cacheValue[2] = payload.exp * 1000 + clockTolerance
-      } else if (maxAge) {
-        cacheValue[2] = payload.iat * 1000 + maxAge + clockTolerance
-      }
-    }
+  if (!ignoreExpiration && typeof payload.exp === 'number') {
+    expiresAt = Math.min(expiresAt, payload.exp * 1000 + clockTolerance)
+  }
+
+  // As in its validator, maxAge counts from iat and ignores clockTolerance
+  if (typeof maxAge === 'number' && typeof payload.iat === 'number') {
+    expiresAt = Math.min(expiresAt, payload.iat * 1000 + maxAge)
+  }

The fix always evaluates exp independently of iat and bounds the cache deadline by the minimum of cacheTTL, exp, and maxAge. Source: GitHub Commit fc1ddbb.

Detection Methods for CVE-2026-107719

Indicators of Compromise

• Repeated use of the same bearer token across requests spanning longer than its original exp lifetime.
• Authenticated sessions continuing after expected token expiration without a visible token refresh event.
• Access logs showing JWTs with exp but missing iat claims being accepted by the application.

Detection Strategies

• Inventory Node.js services for fast-jwt versions below 6.3.4 using SBOM data or npm ls fast-jwt.
• Instrument the auth layer to log token jti, iat, and exp values and alert on reuse of a jti after its exp.
• Review issuer configurations to identify flows that emit JWTs without an iat claim.

Monitoring Recommendations

• Track authentication event volume per token identifier and alert on anomalies that outlive the configured token lifetime.
• Monitor dependency manifests in CI pipelines for pinned or transitive fast-jwt versions prior to 6.3.4.
• Correlate API access patterns with session issuance timestamps in your SIEM to surface expired-token acceptance.

How to Mitigate CVE-2026-107719

Immediate Actions Required

• Upgrade fast-jwt to version 6.3.4 or later across all services and container images.
• Rebuild and redeploy applications that bundle fast-jwt as a transitive dependency.
• Rotate signing keys if there is evidence of token replay abuse in logs.

Patch Information

The fix is released in fast-jwt 6.3.4. See the GitHub Release v6.3.4 and the GitHub Security Advisory GHSA-x937-hj6v-793p. The patched cacheSet always applies exp and maxAge bounds to the cache deadline, independent of whether iat is present.

Workarounds

• Disable the verifier cache by passing cache: false to createVerifier until the upgrade is deployed.
• Reduce cacheTTL to a value at or below the shortest expected token lifetime to limit replay windows.
• Require iat on all issued tokens and reject tokens missing iat at the application layer.

# Update fast-jwt to the patched release
npm install fast-jwt@^6.3.4

# Verify installed version
npm ls fast-jwt

# Temporary mitigation: disable verifier cache in application code
# const verifier = createVerifier({ key, cache: false })