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

CVE-2026-107724 Overview

CVE-2026-107724 affects fast-jwt, a widely used Node.js library providing a fast JSON Web Token (JWT) implementation. Version 6.2.4 misclassifies raw serialized public JSON Web Key (JWK) or JSON Web Key Set (JWKS) data as HMAC secret material. The flaw lives in performDetectPublicKeyAlgorithms within src/crypto.js, which treats any non-PEM string as symmetric key bytes. An attacker who knows the exact serialized public-key bytes can use them as an HMAC key and forge tokens that createVerifier accepts with arbitrary claims. The issue is fixed in version 6.3.0 and tracked as [CWE-347: Improper Verification of Cryptographic Signature].

Critical Impact
Attackers who obtain or guess the exact byte representation of a public JWK can forge valid JWTs, impersonating any user and bypassing authentication when HS256 is allowed or inferred.

Affected Products

fast-jwt version 6.2.4 (nearform/fast-jwt)
Node.js applications using createVerifier with HS256 allowed or algorithm inference enabled
Services distributing public JWK/JWKS material alongside symmetric-algorithm support

Discovery Timeline

2026-10-08 - CVE-2026-107724 published to the National Vulnerability Database
2026-10-09 - Last updated in NVD database
v6.3.0 - Fix released in fast-jwt v6.3.0

Technical Details for CVE-2026-107724

Vulnerability Analysis

The vulnerability is a classic JWT algorithm confusion flaw. fast-jwt inspects a provided key to infer its type. The performDetectPublicKeyAlgorithms function in src/crypto.js only recognizes PEM-encoded material through regular expressions matching -----BEGIN ... KEY----- headers. Any string that does not match a PEM header is classified as a symmetric secret suitable for HMAC algorithms such as HS256.

This logic breaks when an application loads a public JWK or JWKS as a raw JSON string and passes it to createVerifier. The library accepts the serialized JSON bytes as a valid HMAC secret. An attacker who can reproduce the exact byte sequence of that public JWK can compute HMAC-SHA256(publicKeyBytes, header + '.' + payload) and produce a token the verifier accepts.

Root Cause

The root cause is permissive key-type inference. The detection routine assumed non-PEM input must be symmetric material, ignoring the possibility of structured asymmetric key representations. Public JWKs are explicitly designed to be shared, so treating them as secrets collapses the trust boundary between public and private key material.

Attack Vector

Exploitation requires that HS256 be explicitly listed in the allowed algorithms or inferred by the verifier, and that the attacker possess the exact serialized byte representation of the public key. Serialization ordering, whitespace, or Unicode differences between the attacker's copy and the server's copy prevent the HMAC from matching. Applications using supported PEM keys with an asymmetric-only algorithm allowlist are not affected.

javascript

// Patch excerpt from src/crypto.js (fast-jwt v6.3.0)
const privateKeyPemMatcher = /^-----BEGIN(?: (RSA|EC|ENCRYPTED))? PRIVATE KEY-----/
const publicKeyPemMatcher = /^-----BEGIN(?: (RSA))? PUBLIC KEY-----/
const publicKeyX509CertMatcher = '-----BEGIN CERTIFICATE-----'
// kty values that identify asymmetric JWK key material (RFC 7518 / RFC 8037).
// "oct" (a genuine symmetric key) is deliberately excluded so raw HS* JWKs keep working.
const asymmetricJwkKtys = new Set(['RSA', 'EC', 'OKP'])

Source: GitHub Commit 10f9591. The fix parses candidate JSON input and rejects it as an HMAC secret when its kty field identifies asymmetric key material.

Detection Methods for CVE-2026-107724

Indicators of Compromise

JWTs with an alg header value of HS256 arriving at endpoints that are supposed to use RS256, ES256, or EdDSA
Authentication log entries showing accepted tokens for high-privilege accounts without a corresponding login event
Unexpected claim values such as elevated roles or administrative scopes in otherwise routine sessions

Detection Strategies

Enumerate dependency manifests across Node.js services for fast-jwt@6.2.4 using npm ls fast-jwt or software composition analysis tooling
Inspect application code for calls to createVerifier that omit an explicit algorithms allowlist or include HS256 alongside asymmetric algorithms
Review how JWK/JWKS material is loaded; flag any code path that passes a raw JSON string to the verifier rather than a parsed public key

Monitoring Recommendations

Log and alert on JWT verifications where the token header algorithm does not match the expected asymmetric algorithm for the issuer
Correlate authentication events with upstream identity provider logs to detect tokens accepted without a matching issuance
Monitor outbound traffic from applications known to expose JWKS endpoints for scraping patterns that precede forgery attempts

How to Mitigate CVE-2026-107724

Immediate Actions Required

Upgrade fast-jwt to version 6.3.0 or later across all Node.js services
Audit every createVerifier call site and enforce an explicit algorithms allowlist containing only the asymmetric algorithms in use
Rotate any JWT signing keys that may have been exposed if forged tokens are suspected in logs

Patch Information

The fix is published in fast-jwt v6.3.0 via Pull Request #636. Full technical context is available in GHSA-g3jj-5cmm-3hxx. The patch introduces an asymmetricJwkKtys set and parses candidate secrets as JSON to reject structured asymmetric keys before HMAC classification.

Workarounds

Restrict the verifier to asymmetric algorithms only by passing { algorithms: ['RS256'] } (or the equivalent for your deployment) to createVerifier
Load public keys as PEM strings rather than raw JWK or JWKS JSON when feasible
Reject tokens whose header alg field does not match the configured asymmetric algorithm at an API gateway or middleware layer

bash

# Upgrade fast-jwt and lock the fixed version
npm install fast-jwt@^6.3.0
npm ls fast-jwt

# Verify no transitive dependency pins 6.2.4
npm why fast-jwt