fast-jwt CVE-2026-107719

Exploitation requires ALL of: (1) the verifier created via createVerifier with caching enabled (cache: true); (2) tokens that contain an exp claim but NO iat claim (e.g., signed with noTimestamp), since cacheSet only derives the exp-based cache deadline when iat is present; and (3) an attacker able to replay the same previously-valid bearer token they already hold. Limiting factors that reduce real-world risk: caching is an opt-in configuration (not default); the attacker cannot forge or alter a token, only replay their own; and acceptance is capped at the cache entry's TTL (cacheTTL default 600000 ms / 10 minutes), after which normal expiration rejection resumes. Applications whose tokens include iat, or that run without the cache, are not affected.

This is a genuine but low-to-moderate priority issue, well-aligned across the available signals. The vendor-confirmed CVSS 3.1 vector (AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N, base 4.2 Medium) is internally consistent with the GHSA advisory: AC:H reflects the narrow preconditions (caching must be enabled AND the token must carry exp without iat), PR:L reflects that the attacker must already possess a legitimately-issued, previously-valid signed token, and the Low confidentiality/integrity impacts match a session-expiration bypass (CWE-613) that extends - but does not forge - access. No EPSS score, no CISA KEV listing, and no standalone public exploit were provided, so exploitation status is 'no public exploit identified at time of analysis'; however, the advisory contains a detailed step-by-step reproduction timeline and the fix commit ships working regression tests, which lowers the barrier to building a PoC even though none is published. There is no SSVC decision data in the input. The impact is self-limited: the attacker can only replay their OWN already-valid token, and acceptance ends when the cache entry expires (cacheTTL default 10 minutes), so the practical gain is a bounded extension of access, not privilege escalation or forgery. No signals conflict; the main caveat is that the vulnerable state requires a specific non-default verifier configuration, so blanket 'high risk' framing would overstate it.

An application uses fast-jwt's createVerifier with cache enabled to validate bearer tokens, and its tokens are issued with an exp claim but no iat (e.g., signed with noTimestamp). An attacker who holds a currently-valid token lets it reach its expiry, then replays the identical token; because the first successful verification cached the result with an incorrect deadline falling back to cacheTTL, the cache returns the stored claims before expiration is rechecked. No public exploit is published, but the advisory provides a precise reproduction timeline making exploitation straightforward.