cacheSet only derives its exp cache deadline inside hasIat (src/verifier.js:127-140). JWT iat is optional. For a valid token with exp but no iat, cacheSet substitutes clockTimestamp + clockTolerance + cacheTTL (src/verifier.js:142-146). Later, the cache path returns the saved payload before decoding or invoking verifyToken (src/verifier.js:372-388). Since expiration validation is in verifyToken, the expired token remains accepted until the cache deadline.
The fix for CVE-2026-34950 (CVSS 9.1, released in v6.2.0) is incomplete. It adds key.trim() to the PEM-detection path in src/crypto.js, but String.prototype.trim() only strips characters classified as whitespace by the ECMAScript specification. The subsequent ^-anchored regex (/^—–BEGIN(?: (RSA))? PUBLIC KEY—–/) still requires the PEM header at position 0 — so any non-whitespace leading byte (control chars, zero-width unicode, # comments, HTTP-style headers, PGP wrappers) bypasses detection and falls through to …
createVerifier in fast-jwt ≤ 6.3.0 skips signature verification entirely when the key option is a falsy synchronous value ('' or null) and the algorithms option is set to a non-empty allowlist. An attacker who can present a JWT to the application — regardless of algorithm — can forge arbitrary claims without possessing any signing key.
fast-jwt 6.2.4 silently classifies raw serialized public JWK JSON as an HMAC secret. If an application supplies public JWK JSON text as the verifier key and HS256 is explicitly allowed or automatically inferred, an attacker who knows the same public JSON text can use it as an HMAC key and create an arbitrary HS256 token that fast-jwt accepts as valid. This can result in authentication or authorization bypass through forged …
createVerifier({ clockTolerance: Infinity }) silently bypasses both exp (expiry) AND nbf (not-before) validation. Any expired or not-yet-active token is accepted as valid. The same primitive also corrupts the verifier's internal cache so cached entries inherit infinite validity — they remain valid past a later developer-removed Infinity config until LRU eviction.
fast-jwt's createVerifier silently skips all configured claim validators (exp, nbf, iss, aud, sub, jti, nonce) when a validly-signed JWT carries a JSON array as its payload instead of an object. The verifier reports success while having enforced only the signature. This breaks the library's documented allowedIss / allowedAud / allowedSub / expiry / replay-protection guarantees and violates RFC 7519 §7.2 step 10, which requires the JWT Claims Set to be …
A critical authentication-bypass vulnerability in fast-jwt's async key-resolver flow allows any unauthenticated attacker to forge arbitrary JWTs that are accepted as authentic. When the application's key resolver returns an empty string (''), for example via the common keys[decoded.header.kid] || '' JWKS-style fallback, fast-jwt converts it to a zero-length Buffer, hands it to crypto.createSecretKey, derives allowedAlgorithms = ['HS256','HS384','HS512'] from it, and then verifies the token's signature against an empty-key HMAC. The …
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 /y : Sticky matching This does NOT allow invalid tokens to be accepted, only for valid …
⚠️ IMPORTANT CLARIFICATIONS Affected Configurations This vulnerability ONLY affects applications that: Use RegExp objects (not strings) in the allowedAud, allowedIss, allowedSub, allowedJti, or allowedNonce options Configure patterns susceptible to catastrophic backtracking Example: allowedAud: /^(a+)+X$/ ← VULNERABLE Example: allowedAud: "api.company.com" ← SAFE Not Affected Applications using string patterns for audience validation (most common) Applications using safe RegExp patterns without nested quantifiers Default fast-jwt configurations Assessment Guide To determine if you're affected: …
NOTE: While the library exposes a mechanism which could introduce the vulnerability, this issue is created by developer-supplied code and not by the library itself. We will add a warning and some education for users around the possible issues however since the defaults work we will not be updating the library beyond that for this advisory.
fast-jwt does not validate the crit (Critical) Header Parameter defined in RFC 7515 §4.1.11. When a JWS token contains a crit array listing extensions that fast-jwt does not understand, the library accepts the token instead of rejecting it. This violates the MUST requirement in the RFC.
The fix for GHSA-c2ff-88x2-x9pg (CVE-2023-48223) is incomplete. The publicKeyPemMatcher regex in fast-jwt/src/crypto.js uses a ^ anchor that is defeated by any leading whitespace in the key string, re-enabling the exact same JWT algorithm confusion attack that the CVE patched.