fast-jwt CVE-2026-107721

Exploitation requires that the application be configured with createVerifier({ clockTolerance: Infinity }) - a non-default setting reachable only by someone with control over the verifier's configuration code or options (application administrator or equivalent). This is the explicit precondition and the primary limiting factor: default configurations are not affected. Because the option-validation only rejected negative/non-number values (not Infinity), the infinite value flows as ±Infinity modifiers into validateClaimDateValue, making exp and nbf comparisons always pass. A secondary persistence condition: the verifier's internal LRU cache derives infinite bounds, so cache entries created under this config remain valid even after a developer removes the Infinity setting, until LRU eviction. Once misconfigured, an attacker needs no authentication or user interaction to present an expired/not-yet-active token - the limiting factor is entirely the upstream misconfiguration, not the attacker's access.

This is a genuine-but-conditional weakness that scores moderate (CVSS 5.9) and should be treated as a configuration-hygiene / supply-chain hardening item rather than an urgent remotely-exploitable flaw. The CVSS vector (AV:N/AC:H/PR:H/UI:N) is internally consistent with the description: the high privileges (PR:H) and high complexity (AC:H) reflect that the vulnerability only manifests when an application administrator or equivalent configuration path sets clockTolerance to Infinity - a non-default, developer-chosen value. Exploitation status is 'publicly available exploit code exists' (the GHSA advisory includes a working empirical PoC verified against fast-jwt@HEAD on 2026-06-03); this is NOT the same as active exploitation. The CVE is NOT listed in CISA KEV and no EPSS score was provided in the input, so there is no signal of widespread or automated exploitation - consistent with a flaw that requires a prior misconfiguration to be present. The C:H/I:H impact is justified because accepting expired (exp) and not-yet-active (nbf) tokens defeats session-expiry controls (CWE-613), enabling continued authenticated access with stale tokens. Net: real bug with a confirmed PoC and a confirmed fix, but gated behind an operator mistake - prioritize dependency upgrade and config audit, not emergency patching.

A developer or administrator sets createVerifier({ clockTolerance: Infinity }) (e.g. copied from a clock-skew troubleshooting snippet), which silently disables both exp and nbf checks. An attacker who possesses an expired or stolen-but-lapsed JWT - or a not-yet-valid token - then presents it to the service and is authenticated as the token subject. A public PoC demonstrating acceptance of both expired and future-dated tokens exists in the vendor GHSA advisory.