fast-jwt EUVD-2026-95344

Exploitable ONLY when the application instantiates fast-jwt's createVerifier with a falsy SYNCHRONOUS key - an empty string '' or null - AND simultaneously supplies a non-empty algorithms allowlist (e.g. algorithms: ['HS256']). Under that specific combination, prepareKeyOrSecret is skipped, hasKey is false, and an unsigned token's empty signature bypasses the verifySignature gate. Exploitation is explicitly BLOCKED in these cases (per the advisory): any non-empty/real key, a falsy key with NO algorithms option set, and the asynchronous key-resolver path (key provided as a function/promise) - all of which are unaffected. Claim validators still execute, so time/audience/issuer constraints configured on the verifier continue to apply and can limit a forged token. The required configuration is non-default and developer-introduced, which is the primary real-world limiting factor; no authentication, privileges, or user interaction are needed by the attacker once such a verifier exists.

CVSS 3.1 base score is 7.4 (High) with vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N - network-reachable and requiring no privileges or user interaction, which maps directly to the described authentication/authorization bypass via a forged unsigned JWT. The AC:H rating is the single most important real-risk modifier: the flaw only manifests when an application built createVerifier with a falsy synchronous key ('' or null) AND an explicit non-empty algorithms allowlist. This is a non-default, developer-introduced misconfiguration, not a condition any arbitrary deployment meets, so the pool of actually-exploitable instances is far smaller than the 7.4 score alone implies. No EPSS probability is provided in the input, there is no CISA KEV listing, and no standalone public exploit tool is referenced - so exploitation status is 'no public exploit identified at time of analysis.' However, the nearform GHSA advisory and the merged regression tests document the exact forging technique (forgeUnsignedToken producing a header.payload. token with an empty signature), lowering the skill barrier considerably. Net: this is a genuinely serious bug (trivial to exploit where present, full identity forgery) but its blast radius is bounded by whether a given service uses the vulnerable configuration, not by attacker capability. Treat as high priority for teams that can confirm they use fast-jwt ≤6.3.0 with a falsy key plus an explicit allowlist; lower urgency otherwise. SSVC-style read: exploitation is 'none' observed, automatable is plausible once a vulnerable endpoint is found (token submission is scriptable), technical impact is total for the affected trust boundary.

An attacker targets a Node.js/Fastify service using fast-jwt ≤6.3.0 whose createVerifier was configured with key '' or null and an explicit algorithms allowlist such as ['HS256']. They craft a JWT with a header matching an allowed algorithm and a payload containing arbitrary claims (e.g. {"sub":"admin","admin":true}) followed by an empty signature segment, then submit it to the application. No standalone public exploit is referenced, but the GHSA advisory and merged tests publish the exact unsigned-token forging method; the AV:N/AC:H/PR:N vector means the only real barrier is finding a service running the vulnerable configuration.