fast-jwt: CVE-2026-107722 — RSA→HS256 algorithm confusion

What happened

From 6.2.0 until the fix in 6.3.0, fast-jwt can fail to detect a PEM-formatted RSA public key if the key text has non-whitespace content before its PEM header. Because the detection code trims whitespace but the regular expression used to match PEM remains anchored at the start, comments, control characters, zero-width characters, or wrapper text can prevent PEM recognition and cause the library to fall back to treating the material as an HMAC secret. When HS256 is inferred or permitted, an attacker who knows the public key bytes can use them to sign HS256 tokens that will be accepted. [sources: 4097, 31979]

Technical cause

The vulnerability is in src/crypto.js: performDetectPublicKeyAlgorithms trims leading whitespace but publicKeyPemMatcher is still start-anchored. That mismatch allows non-whitespace prefix characters to bypass PEM detection and reach the HMAC fallback path. The reported CWE classification is CWE-347. [sources: 4097, 31979]

Why it matters

If an RSA public key is misclassified as an HMAC secret, an attacker who knows the public key bytes can craft HS256-signed tokens that validate as legitimate, allowing authentication or authorization bypass in systems that accept HS256 signatures or infer algorithms. The CVSS base score is 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), indicating high impact on confidentiality, integrity, and availability. The advisory's Patchwire score is 6.2, which incorporates the CVSS base and other factors such as unauthenticated remote impact and absence of required user interaction. [sources: 4097, 31979]

Who is affected

Projects and services using the npm package fast-jwt with the vulnerable release range (introduced in 6.2.0 and fixed in 6.3.0) are affected. Systems that accept HS256 signatures or infer algorithms from token content are at risk if they use vulnerable fast-jwt for signature verification or token handling. [sources: 4097, 31979]

Discovery and timeline

The advisory published entries noting the issue on 2026-10-08. The OSV entry (source 4097) and the NVD entry (source 31979) record the vulnerability and the fix timeline. The affected range is recorded as introduced in 6.2.0 and fixed in 6.3.0. [sources: 4097, 31979]

Affected versions

The vulnerability was introduced in fast-jwt 6.2.0 and fixed in fast-jwt 6.3.0. [sources: 4097, 31979]

Fixes and mitigation

A vendor fix is available in fast-jwt 6.3.0. The advisory notes an application-level mitigation: restrict accepted algorithms to an asymmetric-only allowlist (i.e., disallow HS256) so that algorithm confusion cannot be exploited. [sources: 4097, 31979]

Recommended action

1) Upgrade fast-jwt to 6.3.0. 2) If you cannot upgrade immediately, implement an asymmetric-only algorithm allowlist in your JWT verification so HS256 is not accepted. 3) Review any token-accepting endpoints and logs for unexpected HS256 token use. Do not assume public key material is safe to treat as an HMAC secret; ensure libraries correctly detect PEM-formatted keys. [sources: 4097, 31979]