CVE-2026-107722: fast-jwt Auth Bypass Vulnerability

CVE-2026-107722 Overview

CVE-2026-107722 affects fast-jwt, a widely used Node.js JSON Web Token (JWT) library maintained by NearForm. Versions 6.2.0 through 6.2.x misclassify RSA public-key material as an HMAC secret when the PEM payload is preceded by non-whitespace characters. An attacker who possesses the public key bytes can forge valid HS256 tokens signed with that public material. The result is authentication or authorization bypass against applications that infer or allow symmetric algorithms. The maintainers released a fix in version 6.3.0.

Critical Impact

Attackers who know an application's RSA public key can forge arbitrary JWT claims and impersonate any user when HS256 is accepted or inferred by the verifier.

Affected Products

• fast-jwt versions 6.2.0 through 6.2.x
• Node.js applications that rely on fast-jwt for JWT verification
• Services that permit algorithm inference instead of an asymmetric-only allowlist

Discovery Timeline

• 2026-10-08 - CVE-2026-107722 published to NVD
• 2026-10-13 - Last updated in NVD database

Technical Details for CVE-2026-107722

Vulnerability Analysis

The flaw sits in src/crypto.js, inside the performDetectPublicKeyAlgorithms routine. The function trims whitespace from the key material before testing it against publicKeyPemMatcher. That regular expression remains start-anchored, so any non-whitespace content appearing before the -----BEGIN PUBLIC KEY----- header defeats PEM detection. When PEM detection fails, the library falls through to the HMAC path and treats the entire buffer as a shared secret.

This behavior maps to CWE-347: Improper Verification of Cryptographic Signature. The confused-deputy pattern between asymmetric and symmetric algorithms is a long-standing JWT library hazard. The bug reintroduces that class of flaw through a parser edge case rather than an explicit algorithm-mixing bug.

Root Cause

The start-anchored PEM matcher does not account for prepended comments, control characters, zero-width Unicode characters, or arbitrary wrapper text. Trimming only removes standard whitespace, leaving many byte sequences that bypass detection. Because the HMAC fallback uses the raw key bytes as the shared secret, any attacker-known public key becomes a valid signing key for HS256.

Attack Vector

Exploitation requires knowledge of the target RSA public key, which is often published through JWKS endpoints or embedded in client applications. The attacker prepends a benign character sequence to the PEM, computes an HS256 signature over a forged header and claims using the public key bytes as the secret, and submits the resulting token. A verifier that infers algorithms from the token header, or that includes HS256 in its allowlist, will accept the forged token. The vulnerability is remotely exploitable over the network with no privileges or user interaction. See the GitHub Security Advisory GHSA-ww5h-9m49-7xx4 and the patch commit for implementation details.

Detection Methods for CVE-2026-107722

Indicators of Compromise

• JWT tokens arriving with an alg header of HS256 when the service is designed to issue RS256 or another asymmetric algorithm
• Authentication events where the signing key material matches the published public key byte-for-byte
• Successful logins or privilege changes immediately following a token issued with a mismatched algorithm claim

Detection Strategies

• Inventory Node.js services and inspect package-lock.json or yarn.lock for fast-jwt versions between 6.2.0 and 6.2.x
• Add middleware or logging that records the alg value of every verified JWT and alerts on symmetric algorithms where asymmetric is expected
• Perform static analysis for calls to fast-jwt verification APIs that omit an explicit algorithms allowlist

Monitoring Recommendations

• Forward authentication and application logs that capture JWT header metadata to a centralized analytics platform
• Baseline the expected signing algorithm per service and alert on deviations in production traffic
• Track outbound JWKS fetches and public key exposure to understand which keys may be reachable to attackers

How to Mitigate CVE-2026-107722

Immediate Actions Required

• Upgrade fast-jwt to version 6.3.0 or later across all services and container images
• Configure every verifier with an explicit asymmetric-only algorithms allowlist, for example ['RS256'] or ['ES256']
• Rotate RSA key pairs if logs show tokens signed with HS256 against services that should reject symmetric algorithms

Patch Information

The fix is included in fast-jwt v6.3.0 and merged through Pull Request #632. The patch commit hardens key detection so that prepended content no longer routes RSA keys into the HMAC path.

Workarounds

• Pass an explicit asymmetric-only algorithm allowlist to createVerifier, which prevents the HMAC fallback from being reached
• Reject tokens whose alg header does not match the expected signing algorithm at an API gateway or WAF layer
• Avoid passing untrusted or externally sourced key material into verification routines

# Upgrade fast-jwt and pin an asymmetric-only algorithm allowlist
npm install fast-jwt@^6.3.0

# Example verifier configuration (Node.js)
#   const { createVerifier } = require('fast-jwt')
#   const verify = createVerifier({ key: publicKey, algorithms: ['RS256'] })