fast-jwt EUVD-2026-95347

Exploitation requires BOTH: (1) the fast-jwt verifier loads the RSA/EC public key from a source that left non-whitespace content before the '-----BEGIN PUBLIC KEY-----' header - e.g., a '#' or '//' comment line, an HTTP-style header, a PGP/wrapper prefix, or control/zero-width Unicode (NUL, ESC, U+200B zero-width space, U+200D ZWJ, U+FEFF) introduced via DB encoding corruption, YAML inline comments, or copy-paste from formatted documents; and (2) HS256 is inferred or allowed by the verifier. The attacker must also know the target's public key, which is public by definition. The attack is fully PREVENTED by configuring an asymmetric-only algorithm allowlist (so HS256 is never accepted), and clean PEM keys with no leading bytes are not misclassified - these limiting factors mean the default-with-clean-key case is not exploitable despite the AV:N/PR:N CVSS metrics.

The input CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H = 9.8 Critical) presents this as a trivially exploitable remote unauthenticated flaw, but that score overstates real-world exploitability because it ignores two hard preconditions visible in the description and GHSA advisory: the verifier must (a) load the RSA public key from a source that introduced a non-whitespace leading byte, and (b) infer or allow HS256 with no asymmetric-only algorithm allowlist. These are non-default conditions, so AC:L is optimistic - AC:H is more faithful. No EPSS score was provided in the input, and the CVE is NOT on CISA KEV, so there is no evidence of active exploitation; however, a verified 10-line PoC and a full fix PR with regression tests are public, meaning publicly available exploit code exists and the technique (RSA→HS256 algorithm confusion, CWE-347) is well-understood and reliable where the preconditions hold. This is the incomplete-fix successor to CVE-2026-34950 / CVE-2023-48223, a lineage that raises the likelihood of opportunistic testing against known fast-jwt deployments. Net: a genuine high-priority patch item for anyone running fast-jwt 6.2.0-6.2.4 who does not pin an asymmetric algorithm allowlist, but the conditional nature means it is not a blanket internet-wide auto-exploitable 9.8 against every default install.

A service uses fast-jwt (6.2.0-6.2.4) to verify RSA-signed JWTs but loads its public key from a store that prepends non-whitespace content (e.g., a YAML inline comment, a corrupted DB column, or copy-pasted text with a zero-width character). An attacker who knows the public key (public by definition) forges an HS256 token using the public-key bytes as the HMAC secret; because the PEM header is no longer at position 0, fast-jwt misclassifies the key as an HMAC secret and accepts the forged token, bypassing authentication. A verified public PoC exists demonstrating this with the latest affected release.