CVE-2026-107724

fast-jwt is a fast JSON Web Token implementation. Prior to 6.3.0, createVerifier accepts a validly signed JWT whose payload is a JSON array because the decoder does not reject arrays, causing the claim validator loop to silently skip configured checks. An attacker who can produce or influence a validly signed token may bypass expiry, issuer, audience, subject, revocation, and replay protections.

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.

fast-jwt is a fast JSON Web Token implementation. Prior to 6.3.1, createVerifier accepts an unsigned JWT when key is an empty string or null and algorithms is a non-empty allowlist. Falsy synchronous keys bypass prepareKeyOrSecret and the empty signature avoids the verifySignature gate, allowing an attacker to submit a token with arbitrary claims without possessing a signing key.

fast-jwt provides fast JSON Web Token (JWT) implementation. Prior to 6.3.4, the fast-jwt createVerifier cache can continue accepting a previously valid, signed JWT after its exp time when caching is enabled and the token has exp but no iat. In src/verifier.js, cacheSet derives the exp cache deadline only when iat is present, so the cache falls back to cacheTTL, and a later cache hit returns the saved payload before verifyToken rechecks expiration. An attacker who can replay the same cached bearer token can extend access until the cache entry expires, but cannot forge a token through this issue. This issue is fixed in version 6.3.4.

fast-jwt from 6.2.0 until 6.3.0 can misclassify RSA public-key text as an HMAC secret when the key has non-whitespace content before its PEM header. In src/crypto.js, performDetectPublicKeyAlgorithms trims whitespace but publicKeyPemMatcher remains start-anchored, so comments, control characters, zero-width characters, or wrapper text can prevent PEM detection and reach the HMAC fallback. An attacker who knows the public key bytes can sign arbitrary HS256 claims with that public material when HS256 is inferred or allowed, resulting in authentication or authorization bypass. An asymmetric-only algorithm allowlist prevents the attack. This issue is fixed in version 6.3.0.

In versions prior to 6.2.4, the fast-jwt library has a critical authentication-bypass vulnerability that allows unauthenticated attackers to forge arbitrary JWTs accepted as authentic.