CVE-2026-107275: @fastify/jwt vulnerable to missing token expiration when temporal options cannot be parsed
@fastify/jwt is a JSON Web Token plugin for the Fastify web framework. In versions before 10.2.3, a time span passed to expiresIn, notBefore, or maxAge that the plugin's parser cannot read, such as a compound span, a month unit, an ISO 8601 duration, a decimal comma, or a value with surrounding whitespace, is silently dropped instead of refused. On the signing path this produces a token with no expiration claim that never expires, and on the verification path a configured maxAge stops being enforced, so a token that should be rejected for age is accepted. The issue is fixed in @fastify/jwt 10.2.3, and users should upgrade to 10.2.3 or later. As a workaround, pass these options as a number of seconds, or verify that any time-span string parses to a finite value before relying on it.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
@fastify/jwtto a version that resolves this vulnerability.Fixed in 10.2.3 - Configuration
Pass expiresIn, notBefore, and maxAge as a number of seconds, or verify that any time-span string parses to a finite value before relying on it.
@fastify/jwt expiresIn, notBefore, maxAge = number of seconds
Event History
Frequently Asked Questions
Which deployments are affected?
Deployments using @fastify/jwt before version 10.2.3 are affected if they rely on expiresIn, notBefore, or maxAge values that the plugin cannot parse. Numeric values expressed as seconds are identified as a workaround.
What kinds of temporal option values can trigger the issue?
Examples include compound spans, month units, ISO 8601 durations, decimal commas, and values with surrounding whitespace. When such a value cannot be parsed, it is silently dropped rather than rejected.
What must an attacker have to benefit from this behavior?
The issue can allow reuse of a token that was expected to expire or be rejected based on maxAge, if the relevant temporal setting was silently dropped. The provided data does not describe any additional attacker interaction requirements.
How can this be mitigated before upgrading?
Pass expiresIn, notBefore, and maxAge as a number of seconds, or validate that any time-span string parses to a finite value before relying on it. Upgrade to @fastify/jwt 10.2.3 or later when possible.
How can teams determine whether their configuration is at risk?
Review uses of expiresIn, notBefore, and maxAge for non-numeric time-span strings, especially the unsupported formats described. Also check whether issued tokens lack an expiration claim or whether maxAge-based verification accepts tokens beyond their intended age.