CVE-2026-34950: Nearform Fast-jwt Auth Bypass Vulnerability

CVE-2026-34950 Overview

CVE-2026-34950 affects fast-jwt, a high-performance JSON Web Token (JWT) implementation maintained by Nearform for Node.js. Versions 6.1.0 and earlier contain a flawed regular expression in fast-jwt/src/crypto.js that fails to properly validate public key formats. The publicKeyPemMatcher regex uses a ^ anchor that any leading whitespace defeats. This regression re-enables the JWT algorithm confusion attack originally fixed in CVE-2023-48223. Attackers can forge tokens accepted by applications that verify RSA-signed JWTs, leading to authentication bypass and identity impersonation [CWE-327].

Critical Impact
Remote attackers can bypass JWT signature verification and impersonate arbitrary users without credentials, compromising confidentiality and integrity of protected resources.

Affected Products

Nearform fast-jwt versions 6.1.0 and earlier
Node.js applications relying on fast-jwt for JWT verification
Services using RSA public keys for asymmetric JWT validation

Discovery Timeline

2026-04-06 - CVE-2026-34950 published to NVD
2026-04-22 - Last updated in NVD database

Technical Details for CVE-2026-34950

Vulnerability Analysis

The vulnerability re-introduces an algorithm confusion flaw previously addressed in CVE-2023-48223. JWT libraries must enforce strict separation between asymmetric algorithms such as RS256 and symmetric algorithms such as HS256. When a verifier accepts a public key but the attacker controls the alg header, the attacker can sign a forged token using the public key as the HMAC secret. The verifier then validates the token using the same public key, accepting the forgery.

The publicKeyPemMatcher in fast-jwt/src/crypto.js is responsible for detecting whether supplied key material is a PEM-encoded public key. A successful match triggers the asymmetric verification path. A failed match permits fallback to symmetric handling, which the attacker exploits to bypass signature validation.

Root Cause

The regex begins with a ^ anchor intended to require that the PEM header appears at the start of the input. Leading whitespace characters such as spaces, tabs, or newlines preceding -----BEGIN PUBLIC KEY----- defeat the anchor in the matcher's effective behavior. The matcher fails to identify the input as a public key, even though downstream cryptographic routines still treat the trimmed value as a valid key. This inconsistency enables algorithm confusion.

Attack Vector

An attacker crafts a JWT using the HS256 algorithm and signs it with the target service's public key as the HMAC secret. The attacker submits the token to an endpoint that calls fast-jwt to verify signatures. Because the matcher fails to classify the key as asymmetric under specific input conditions, the library accepts the HMAC-signed token as valid. The attacker controls the token claims, including sub, roles, and expiration values, enabling full authentication bypass over the network without prior authorization.

No verified public proof-of-concept code is available. See the GitHub Security Advisory GHSA-mvf2-f6gm-w987 for vendor technical details.

Detection Methods for CVE-2026-34950

Indicators of Compromise

JWT authentication events where the token alg header is HS256 but the application is configured for RSA verification
Successful authentications from sessions whose tokens were signed with HMAC while the service publishes an RSA public key
Sudden appearance of administrative or privileged sessions without corresponding login events in identity provider logs

Detection Strategies

Inventory Node.js applications and identify dependencies on fast-jwt at version 6.1.0 or earlier using npm ls fast-jwt or software composition analysis tooling
Enable verbose JWT verification logging to capture the alg header value and signing key identifier for every verification attempt
Compare expected algorithm allowlists against observed algorithm values in production traffic and alert on deviations

Monitoring Recommendations

Forward authentication and API gateway logs to a centralized analytics platform and baseline normal JWT algorithm distribution per service
Alert when a JWT verification succeeds using HS256 against a service that only issues RSA-signed tokens
Monitor outbound dependency updates and track patched versions of fast-jwt across CI/CD pipelines

How to Mitigate CVE-2026-34950

Immediate Actions Required

Upgrade fast-jwt to the patched release identified in the Nearform security advisory
Audit application code to ensure JWT verification explicitly passes an algorithms allowlist restricted to asymmetric algorithms such as RS256 or ES256
Rotate any RSA key pairs that may have been exposed in tokens or logs while the vulnerable version was in production

Patch Information

Nearform published the fix in the GitHub Security Advisory GHSA-mvf2-f6gm-w987. The patch corrects the publicKeyPemMatcher regex so that leading whitespace no longer defeats the start-of-string anchor and ensures consistent classification of key material.

Workarounds

Configure fast-jwt verifiers with an explicit algorithms parameter containing only the expected asymmetric algorithm, preventing fallback to HMAC verification
Normalize and trim PEM input before passing keys to the library so that no leading whitespace is present
Place a JWT-aware API gateway in front of vulnerable services to reject tokens whose alg header does not match the service's configured algorithm

bash

# Configuration example: enforce algorithm allowlist in fast-jwt verifier
npm install fast-jwt@latest
# In application code, instantiate the verifier with a strict algorithm list:
#   const verifier = createVerifier({ key: publicKeyPem, algorithms: ['RS256'] })