CVE-2026-107275 in fastify-jwt
Summary
by MITRE • 10/08/2026
@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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/08/2026
The @fastify/jwt plugin serves as a critical component for implementing JSON Web Token authentication within the Fastify web framework ecosystem. In versions prior to 10.2.3, a significant security vulnerability exists in how the library parses time-based expiration parameters such as expiresIn, notBefore, and maxAge. The core technical flaw lies in the input validation logic, which fails to strictly enforce expected formats for duration strings. Specifically, when developers pass compound spans, month units, ISO 8601 durations, values containing decimal commas instead of periods, or strings with surrounding whitespace, the parser does not raise an error or reject the invalid input as one might expect from a robust security library. Instead, it silently drops these malformed time specifications and proceeds with default behavior that effectively ignores the intended expiration constraints.
This silent failure leads to two distinct but equally dangerous operational impacts depending on whether the token is being signed or verified. On the signing path, if an invalid expiresIn value is provided, the resulting JWT will lack an exp claim entirely. According to RFC 7519, a missing expiration time means the token never expires by default unless explicitly handled otherwise by downstream logic. This creates tokens with indefinite lifespans, which poses a severe risk in scenarios where session management relies on automatic token rotation or revocation based on age. An attacker who obtains such a token can use it indefinitely to maintain access to protected resources, bypassing any intended time-based security controls designed to limit the window of opportunity for credential theft exploitation.
On the verification path, the vulnerability manifests when verifying tokens that were signed with invalid maxAge configurations or when attempting to enforce age limits on incoming requests. If the parser silently drops a malformed maxAge value during configuration setup, the enforcement mechanism becomes non-functional. Consequently, tokens that should be rejected due to exceeding their allowed maximum age are accepted as valid. This undermines the integrity of short-lived token strategies and allows attackers to reuse old credentials long after they were intended to become obsolete. The combination of these two failure modes effectively neutralizes time-based security controls, leaving applications vulnerable to replay attacks and unauthorized persistent access.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation, as the application fails to adequately sanitize or validate user-supplied configuration data before processing it into critical security logic. It also relates to CWE-613 Insufficient Session Expiration, given that tokens may persist indefinitely due to dropped expiration claims. In terms of MITRE ATT&CK mapping, this flaw facilitates Initial Access and Persistence techniques by allowing attackers to maintain long-term footholds using stolen or replayed credentials without detection from standard token expiry mechanisms. The lack of explicit error reporting also complicates incident response efforts, as developers may not immediately realize that their security configurations are being ignored due to silent parsing failures rather than obvious runtime errors.
To mitigate this risk, organizations must upgrade the @fastify/jwt dependency to version 10.2.3 or later, where these parsing issues have been resolved and strict validation is enforced for time-span inputs. For environments that cannot immediately patch the library, a defensive coding workaround involves ensuring that all time-related options are passed as numeric values representing seconds rather than complex string formats. Additionally, developers should implement custom middleware to validate any configuration objects before they reach the JWT plugin, explicitly checking that parsed duration values result in finite numbers and rejecting requests or configurations that do not meet these criteria. This proactive validation layer ensures that security parameters are applied correctly even if underlying library versions vary across different parts of a microservices architecture.