CVE-2026-107722: Algorithm Confusion via Non-Whitespace Prefix Bypass in fast-jwt

The fast-jwt library is a high-performance JSON Web Token implementation designed for Node.js environments. In versions 6.2.x prior to 6.3.0, it contains a critical vulnerability that allows asymmetric-to-symmetric algorithm confusion. This attack vector allows an unauthenticated remote attacker to bypass cryptographic signature verification and gain unauthorized access to target applications.

The vulnerability is rooted in how the library auto-detects the format of the key supplied to the verifier. When a verifier is initialized without an explicit, restrictive algorithm allowlist, it evaluates the key format to determine whether to perform asymmetric (RS*/ES*) or symmetric (HS*) signature verification. Because the auto-detection routine depends on matching anchored regular expressions, the presence of specific non-whitespace leading prefixes causes the parser to fail back to symmetric validation.

An attacker who knows or can obtain the server public key can exploit this fallback. By signing a forged token with the public key as the shared HMAC secret, the attacker triggers verification using the symmetric pipeline. This completely invalidates the integrity guarantees of the token and allows full system access.

The root cause of CVE-2026-107722 is an incomplete patch for an earlier key-parsing vulnerability, CVE-2026-34950. The previous security fix attempted to protect the anchored regular expressions by calling String.prototype.trim() on the key input before matching headers. However, the standard ECMAScript trim operation only removes whitespace characters, leaving any leading non-whitespace characters intact.

Key detection regular expressions are anchored to the start of the string using the '^' character. For example, the parser identifies public keys via /^-----BEGIN(?: (RSA))? PUBLIC KEY-----/. When the key contains non-whitespace prefixes—such as database comments, control characters, or protocol headers—the regular expression fails to match.

Because the anchored check fails, the library assumes the key is not a PEM-formatted asymmetric key. Instead of throwing an error or rejecting the invalid input, the verification engine falls back to treating the key as a raw, symmetric HMAC shared secret. The entire prefixed public key string is then registered as the symmetric HMAC key.

In vulnerable versions of src/crypto.js, the key sanitization code relies entirely on standard string trimming:

// Vulnerable logic in fast-jwt < 6.3.0
function performDetectPublicKeyAlgorithms(key) {
  const trimmedKey = key.trim()
  const publicKeyPemMatch = trimmedKey.match(publicKeyPemMatcher) 
  // If key begins with non-whitespace prefix, publicKeyPemMatch is null
  if (!publicKeyPemMatch) {
    return hsAlgorithms // Falls back to symmetric HMAC algorithms
  }
}

In the patched version (v6.3.0), the library introduces a centralized, non-anchored PEM locator function. This function scans the entire key string to identify the position of the standard PEM boundary, preventing bypasses caused by arbitrary prefixes:

// Patched logic in fast-jwt 6.3.0
const pemBeginMatcher = /-----BEGIN [A-Z0-9 ]+?-----/
 
function locatePem(trimmedKey) {
  const pemStart = trimmedKey.search(pemBeginMatcher)
  if (pemStart === -1) {
    return { pem: null, isRawSecret: true }
  }
  return { pem: trimmedKey.slice(pemStart), isRawSecret: false }
}

The update ensures that any string containing a valid PEM block is correctly isolated and processed as an asymmetric key, regardless of preceding data. It also throws a definitive TokenError if a PEM header is recognized but is unsupported, eliminating silent fallbacks.

An attacker targets applications that do not enforce explicit verification algorithms. If the application loads a public key containing a leading comment or non-whitespace prefix, the attacker can leverage the algorithm confusion flaw.

The attacker retrieves the public key and generates a malicious JWT. The header is configured with the 'alg' field set to 'HS256' to instruct the server to use symmetric verification. The payload is configured with arbitrary claims, such as administrative access privileges.

The attacker signs the token using HMAC-SHA256, utilizing the full, prefixed public key string as the shared secret key. When the application receives the token, the fast-jwt verifier evaluates the header algorithm as 'HS256', resolves the verification key as a symmetric secret due to the failed PEM check, and verifies the signature successfully.

The impact of successful exploitation is a complete compromise of the token validation mechanism. An attacker can forge JWTs containing arbitrary identity claims and permissions, bypassing authentication and authorization controls without possessing the server private key.

This flaw is classified under CWE-347 (Improper Verification of Cryptographic Signature) and has a CVSS v3.1 base score of 9.8. Exploitation is highly reliable, requiring no user interaction and low attack complexity. Applications that automatically load public keys from external databases or environment configuration strings are particularly exposed if those inputs contain metadata prefixes.

To resolve this vulnerability, upgrade fast-jwt to version 6.3.0 or higher. The updated package eliminates the vulnerable validation paths by extracting the PEM block correctly using the non-anchored locatePem implementation.

As a defense-in-depth measure, developers must configure verifiers with an explicit list of allowed algorithms. This completely disables key auto-detection and prevents algorithm-confusion bypasses by rejecting any token signed with an unexpected algorithm:

const { createVerifier } = require('fast-jwt')
const fs = require('fs')
 
const publicKey = fs.readFileSync('public.pem', 'utf8')
 
// Secure configuration bypassing auto-detection
const verify = createVerifier({
  key: publicKey,
  algorithms: ['RS256']
})