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.

Affected: npm: fast-jwt

### 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 } ```…