CVE-2026-107721: Time Validation Bypass in NearForm fast-jwt due to Loose Temporal Option Validation

The JSON Web Token (JWT) library fast-jwt is optimized for high-performance claim verification in Node.js applications. A critical aspect of JWT verification is checking temporal boundaries, specifically that the token has not expired (exp claim) and is currently active (nbf claim). The vulnerability surfaces when initializing the verifier using the createVerifier function with specific temporal configuration arguments.

Prior to version 6.3.0, fast-jwt failed to enforce strict finiteness constraints on parameters including clockTolerance, clockTimestamp, and cacheTTL. The library verified that these parameters were of type 'number' and not less than zero, but did not assert that they were finite values. Under JavaScript's type specification, Infinity is a primitive value of type 'number', meaning it bypassed the library's initial validation checks.

When a backend application exposes configuration options or parses environment variables that feed into createVerifier without strict sanitization, an attacker or misconfiguration can specify Infinity as the value for clockTolerance. This results in the complete negation of temporal validation rules, causing the verifier to accept expired or inactive tokens unconditionally.

The root cause of this vulnerability lies in the loose validation logic within src/verifier.js and JavaScript's handling of non-finite numbers. The original validation pattern checked whether options were defined, of the 'number' type, and positive. Because typeof Infinity evaluates to 'number' and the comparison Infinity < 0 yields false, the value Infinity successfully passes this validation block.

When verifying a token, fast-jwt calculates the adjusted expiration time by adding the clockTolerance to the token's exp claim, represented as: adjustedExpiration = payload.exp * 1000 + clockTolerance. If clockTolerance is Infinity, the math evaluates as: payload.exp * 1000 + Infinity = Infinity. The temporal verification check subsequently compares the current system epoch time (now) to the adjusted expiration: now <= Infinity. Since any finite current time is less than or equal to Infinity, this validation always evaluates to true, causing expired tokens to be accepted.

This flaw also affects the Not-Before (nbf) activation claim. The adjusted activation boundary is calculated as: adjustedNotBefore = payload.nbf * 1000 - clockTolerance. With clockTolerance set to Infinity, this calculation yields -Infinity. The verifier checks if now >= -Infinity, which always evaluates to true. This enables the successful use of tokens intended for future execution. Additionally, because validation states are stored in an internal Least Recently Used (LRU) cache, these infinite bounds poison cache keys, keeping entries valid indefinitely.

An examination of the vulnerable code in src/verifier.js reveals how loose validation permitted non-finite numbers to pass through checks:

// Vulnerable Code Path
if (clockTolerance && (typeof clockTolerance !== 'number' || clockTolerance < 0)) {
  throw new TokenError(TokenError.codes.invalidOption, 'The clockTolerance option must be a positive number.')
}

The validation block only executed if clockTolerance was truthy. A value of NaN is falsy, allowing it to bypass the validation block entirely and reach calculation phases, where it caused different analytical errors. For Infinity, the condition typeof clockTolerance !== 'number' evaluated to false, and clockTolerance < 0 also evaluated to false, allowing the configuration to be set.

To correct this, the patch introduced explicit checks for defined options (rather than truthiness checks) and added the Number.isFinite() validation check:

// Patched Code Path in src/verifier.js
if (
  clockTolerance !== undefined &&
  (typeof clockTolerance !== 'number' || !Number.isFinite(clockTolerance) || clockTolerance < 0)
) {
  throw new TokenError(
    TokenError.codes.invalidOption,
    'The clockTolerance option must be a finite, non-negative number.'
  )
}

By checking clockTolerance !== undefined, the parser ensures that falsy but invalid values like NaN trigger an exception instead of bypassing validation. Applying !Number.isFinite() explicitly identifies and blocks Infinity, -Infinity, and NaN, restricting input values to valid finite float or integer ranges.

Exploitation of CVE-2026-107721 relies on a system design flaw where dynamic variables can dictate the configuration of the verifier. If an administrator console, an external database configuration, or a parsed query parameter allows setting the clockTolerance configuration to Infinity, the backend verifier becomes compromised.

Once configured, an attacker can construct an expired JWT or a token designated for future use and transmit it to the application API. The verifier processes the token, evaluates the temporal claims against Infinity boundaries, and yields a valid verification status. The application then processes the request, granting authorized access to protected assets.

The resulting validation outcome is indexed within the LRU cache using keys containing the infinite limits. This means subsequent validation requests can be satisfied directly from the poisoned cache state, maintaining authorization bypass conditions even if the underlying validation variables are temporarily updated.

The impact of this vulnerability is an authorization bypass that invalidates key security constraints of JSON Web Tokens. In environments utilizing short-lived session tokens to enforce security boundaries, the inability to expire credentials permits unauthorized, prolonged access to backend resources.

The CVSS v3.1 base score of 5.9 reflects a Medium severity classification, with the vector CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N. The High Attack Complexity metric denotes that the attack vector depends on the target application propagating unsafe or raw administrative inputs into the library's initialization options.

While this bug does not directly result in Remote Code Execution (RCE) or service disruption, the failure of temporal validation mechanisms undermines security controls, allowing unauthorized entities to perform actions with stale privileges or bypass time-based credential activation schedules.

The recommended remediation is upgrading the fast-jwt package to version 6.3.0 or later, which contains the official fix. This can be accomplished by updating the dependency in the application's configuration files and executing the package manager update:

npm install fast-jwt@latest

If upgrading is not immediately possible, implement external validation to sanitize input parameters prior to initializing the verifier. Developers should ensure that any numeric parameter mapped to clockTolerance, clockTimestamp, or cacheTTL is verified with Number.isFinite() and validated to be non-negative:

function validateVerifierOptions(options) { 
  const keys = ['clockTolerance', 'clockTimestamp', 'cacheTTL'];
  for (const key of keys) {
    if (options[key] !== undefined) {
      if (typeof options[key] !== 'number' || !Number.isFinite(options[key]) || options[key] < 0) {
        throw new Error(`Invalid value for ${key}`);
      }
    }
  }
}

Static analysis can assist in identifying unsafe usage. Code review processes should scan for initialization configurations where createVerifier receives options derived from unsanitized administrative configurations or dynamic external input.