@fastify/jwt CVE-2026-110024

Exploitation requires the application to call the top-level @fastify/jwt sign and/or verify methods while passing per-call options AND relying on globally configured temporal defaults (expiresIn for signing, maxAge for verifying); those global defaults are then silently dropped, producing tokens with no exp claim and verification that no longer enforces maximum token age. Applications that use the route-level sign/verify decorators, or that restate expiration/maxAge in every per-call option object, are NOT affected. Limiting factors: the vulnerable coding pattern must be present (non-universal), the attacker must already possess or capture a valid token to benefit from its non-expiry, and version must be prior to 10.2.5.

This is a moderate, conditional risk rather than an urgent priority. The CVSS 3.1 base score of 6.8 (AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N) reflects network reachability but high attack complexity and a requirement for some privilege (a valid token). No EPSS score, CISA KEV listing, or public POC was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The core weakness (CWE-613, insufficient session expiration) is a logic/API-usage flaw: it only bites applications that call the top-level sign/verify methods with per-call options while depending on global defaults for temporal protections - the route-level decorators correctly merge and are unaffected. The high confidentiality/integrity impact is realistic only once this coding pattern is present, which is why AC:H is justified. Net: a genuine but defense-in-depth-dependent issue whose real-world severity hinges on whether a given deployment actually uses the vulnerable API pattern; absent exploitation telemetry, treat it as a patch-on-normal-cycle item unless the affected API usage is confirmed in your code.

A Fastify application uses the top-level jwt.sign with per-call options (e.g., a custom audience) while relying on a global expiresIn/maxAge default; the resulting tokens silently carry no expiration and never expire. An attacker who obtains such a token - via theft, logging, phishing, or a leaked session - can reuse it indefinitely because verification no longer enforces the configured maximum age. No public exploit code was identified; exploitation requires first obtaining a valid (now non-expiring) token.