fast-jwt

### Summary `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 JSON object. ### Details The decoder validates the **header** is a non-array object but the **payloa

CVE: CVE-2026-107723

## Summary `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. ## Vulnerable code `src/verifier.js:531-533` — option validation only rejects negative values, not Infinity: ```js if (clockTolerance && (typeof clockTolerance !== 'number' || clockTolerance < 0)) { throw new To

CVE: CVE-2026-107721

### Summary `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. ### Details **Root cause — four cooperating code paths:** **A. Falsy sync keys bypass `prepareKeyOrSecret`** `createVerifier` branches on `typeof key`: ```js const keyType = typeof key if (keyType !== 'string' && keyType !== 'obje

CVE: CVE-2026-107720

### Summary `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 JWT claims. The PoC demonstrates the issue with a serialized RSA public JWK. The same non-PEM classification also applies to raw JWKS JSON text, although

CVE: CVE-2026-107724

### Summary 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 the HMAC verification path, using the RSA pu

CVE: CVE-2026-107722

### Summary `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. ### Details The bug is an expiration-check bypass caused by caching. Normally, verification works li

CVE: CVE-2026-107719

### Summary 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 attacker simply computes `HMAC-SHA256

CVE: CVE-2026-44351

## Impact 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 tokens to be improperly rejected in some configurations. Instead it causes **50% of valid authentication requests to f

CVE: CVE-2026-35040

## ⚠️ 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 configuration

CVE: CVE-2026-35041

## Summary `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. --- ## RFC Requirement RFC 7515 §4.1.11: > If any of the listed extension Header Parameters are **not understood > and supported** by the recipient, then the **JWS is invalid**. --- ## Proof of Concept ```javascript const { createSigner, createVerifier } = require("fast-jwt"); //

CVE: CVE-2026-35042