CVE-2026-107721 in fast-jwt
Summary
by MITRE • 10/09/2026
fast-jwt provides fast JSON Web Token (JWT) implementation. Prior to 6.3.0, fast-jwt createVerifier accepts Infinity for clockTolerance because its option validation checks type and negativity but not finiteness. In validateClaimDateValue, infinite positive and negative modifiers make exp and nbf comparisons always pass, allowing expired or not-yet-active tokens to be accepted. The verifier cache also derives infinite bounds, so entries created under this configuration can remain valid until eviction. Exploitation requires an application administrator or equivalent configuration path to set clockTolerance to Infinity. This issue is fixed in version 6.3.0.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/09/2026
The fast-jwt library serves as a high-performance implementation for JSON Web Token processing, widely adopted in Node.js environments for authentication and authorization workflows. A critical logical flaw exists within the token verification logic prior to version 6.3.0, specifically concerning the handling of the clockTolerance configuration parameter. This vulnerability stems from insufficient input validation during the initialization of the verifier instance. While the library correctly checks that the provided value is a number and ensures it is non-negative, it fails to verify whether the value is finite. Consequently, passing Infinity as the clockTolerance value bypasses these basic safeguards, leading to undefined behavior in time-based claim validations.
The technical core of this vulnerability lies in how date claims such as expiration (exp) and not-before (nbf) are evaluated against the current system time. The validation function validateClaimDateValue performs arithmetic operations involving the clockTolerance value when determining if a token is within its valid window. When Infinity is used, any finite number added to or subtracted from it results in Infinity. In JavaScript's IEEE 754 floating-point standard comparisons, an infinite bound effectively removes the temporal constraint for that specific direction of time. For expiration checks, this means the condition checking if the current time exceeds the token's expiry date always evaluates to false because infinity is greater than any finite timestamp. Similarly, for not-before claims, the check ensuring the token has become active also passes trivially since negative infinity is less than any real-world timestamp.
This logical flaw allows an attacker or misconfigured application to accept tokens that are either significantly expired or have not yet reached their intended activation time. The impact is particularly severe because fast-jwt employs a caching mechanism for verified tokens and their associated configurations. When the verifier cache derives infinite bounds due to this configuration error, it stores entries with effectively unlimited validity periods. These cached entries remain valid until they are evicted from memory based on size or age limits unrelated to token expiration. This persistence amplifies the risk, as multiple requests can be authenticated using stale credentials without re-evaluating their temporal constraints against current time.
The exploitation of this vulnerability requires a specific privilege level and access path. It is not remotely exploitable by an unauthenticated attacker directly through network inputs alone. Instead, it necessitates that an application administrator or a component with configuration authority explicitly sets the clockTolerance option to Infinity during the initialization of the JWT verifier. This could occur in scenarios where dynamic configuration loading from external sources fails to sanitize numeric values properly, or if developers mistakenly assume that Infinity represents a very large number rather than a mathematical concept that breaks comparison logic. The threat model assumes trust in the initial setup phase but highlights how improper validation at this stage can undermine runtime security controls.
To mitigate this issue and prevent similar logical flaws in cryptographic libraries, strict input validation must be enforced for all configuration parameters affecting security boundaries. Developers should ensure that numeric inputs are not only of the correct type and sign but also finite, using checks such as Number.isFinite() before passing values to verification functions. Upgrading fast-jwt to version 6.3.0 or later resolves this vulnerability by implementing proper finiteness checks during option validation. This update ensures that invalid configurations like Infinity are rejected early in the process, preventing the creation of verifier instances with broken temporal logic.
From a standards perspective, this flaw aligns with CWE-20 Improper Input Validation and CWE-613 Insufficient Session Expiration. The failure to validate the finiteness of a numeric parameter allows for an unintended state that bypasses security controls defined by JWT specifications regarding time-based claims. In terms of attack patterns, this relates to MITRE ATT&CK techniques involving token manipulation or abuse of authentication mechanisms where temporal constraints are ignored. By ensuring robust validation at configuration boundaries and maintaining up-to-date dependencies, organizations can maintain the integrity of their session management systems against such logical bypasses.