fast-jwt vulnerabilities

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.

fast-jwt is a fast JSON Web Token implementation. In 6.2.4, it can misclassify raw serialized public JWK or JWKS JSON as an HMAC secret because performDetectPublicKeyAlgorithms treats non-PEM strings as symmetric key material. If HS256 is explicitly allowed or inferred, an attacker who knows the exact serialized public-key bytes can use them as an HMAC key and create a token with arbitrary claims.

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 versions 5.0.0 to 6.2.0 have a denial-of-service condition when the allowedAud verification option is configured with a regular expression. Because the aud claim is attacker-controlled, a crafted JWT can trigger catastrophic backtracking in the JavaScript regex engine, causing significant CPU consumption. This is fixed in 6.2.1.

fast-jwt provides fast JSON Web Token (JWT) implementation. Prior to 6.2.1, using certain modifiers on RegExp objects in the allowedAud, allowedIss, allowedSub, allowedJti, or allowedNonce options in verify functions can cause certain unintended behaviours. This is because some modifiers are stateful and will cause failures in every second verification attempt regardless of the validity of the token provided. Such modifiers are /g (global matching) and /y (sticky matching). This does NOT allow invalid tokens to be accepted, only for valid tokens to be improperly rejected in some configurations. Instead it causes 50% of valid authentication requests to fail in an alternating pattern. This vulnerability is fixed in 6.2.1.