@fastify/jwt EUVD-2026-94851

Exploitation requires the affected application to pass expiresIn, notBefore, or maxAge a time-span STRING in a format the plugin's parser cannot read - specifically a compound span (e.g. '1h30m'), a month unit (e.g. '1 month'), an ISO 8601 duration, a value using a decimal comma, or a value with surrounding whitespace. This is a non-default developer misconfiguration; applications that pass these options as a numeric count of seconds, or that use only simple parseable spans, are not affected. On the signing path the condition yields tokens with no exp claim (never expire); on the verification path it disables maxAge age-rejection. Limiting factors: the specific unparseable string must actually be in use, and an attacker generally needs to already possess a token (their own aged token or a stolen/leaked one) to derive benefit, which bounds real-world impact below the raw network-facing surface.

The input CVSS 3.1 vector (AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N, base 6.8, Medium) is internally consistent with the description: exploitation is network-facing but gated behind AC:H because it only manifests when a developer supplies a time-span string in one of the specific unparseable formats (compound span, month unit, ISO 8601 duration, decimal comma, or surrounding whitespace), and PR:L reflects that an attacker typically needs a token to benefit. No EPSS score was provided in the input, so exploitation probability cannot be quantified. This is NOT in CISA KEV and no public exploit code is referenced, so exploitation status is 'no public exploit identified at time of analysis.' Net assessment: this is a real but conditional weakness rather than a mass-exploitation priority - the dangerous outcome (non-expiring tokens / unenforced maxAge) only occurs in applications that happen to use the affected string formats, which is a developer misconfiguration rather than a default state. The C:H/I:H rating is reasonable because indefinitely valid tokens enable prolonged unauthorized authenticated access, but the Medium score and AC:H correctly signal this should be prioritized by teams running affected configurations, not treated as an urgent internet-wide emergency. EPSS is missing - treat likelihood as unquantified rather than low.

A development team configures @fastify/jwt with a human-friendly lifetime such as expiresIn: '1 month' or a compound '1h30m', which the plugin's parser silently drops, so issued JWTs carry no exp claim and never expire. An attacker who obtains such a token - for example a leaked, logged, or previously stolen session JWT - can replay it indefinitely, and on the verification side a configured maxAge that should reject an aged token no longer does. No public proof-of-concept is referenced for this issue.