CVE-2026-107720: Signature Verification Bypass in NearForm fast-jwt

The NearForm fast-jwt library is a high-performance JSON Web Token (JWT) parsing and verification utility for Node.js environments. Applications rely on this library to validate the integrity and authenticity of authentication tokens presented by clients. The vulnerability exposed in CVE-2026-107720 resides in the input validation and signature enforcement boundaries during the verifier initialization and token verification phases.

When developers initialize the token verifier, they supply cryptographic secrets or public keys alongside a set of allowable signature algorithms. The attack surface is exposed when these systems are configured dynamically, and key resolution yields falsy parameters such as an empty string ('') or null. Under this configuration, the engine fails to raise an exception, leading to an insecure operational state.

This security vulnerability is cataloged under both CWE-20 (Improper Input Validation) and CWE-347 (Improper Verification of Cryptographic Signature). By abusing this logical flaw, remote attackers can craft a token structure that explicitly bypasses the cryptographic check, allowing the modification of claims and the execution of unauthorized actions within the system.

The root cause of this vulnerability lies in a systemic logical disconnect between createVerifier (the instantiation routine) and verifyToken (the token evaluation routine).

During verifier setup, if an explicit algorithms list is supplied alongside a falsy key value, the initialization logic evaluates typeof key. Because typeof '' evaluates to 'string' and typeof null evaluates to 'object', the basic type validation passes successfully. The configuration then encounters a conditional execution block designed to prepare cryptographic secrets:

if (key && keyType !== 'function') {
  prepareKeyOrSecret();
}

Because the key is falsy, the if condition evaluates to false, and the preparation routine is completely bypassed. This bypass is critical because prepareKeyOrSecret() contains the key length assertions that would otherwise trigger an immediate error. Because no exception is thrown, the verifier is returned in an active but uninitialized state with hasKey set to false.

When an incoming token is checked, the validation logic evaluates whether a key and signature exist. If an attacker submits an unsigned token, both hasKey and the token signature are falsy. The logic evaluates the check !hasKey && !signature as true, which causes the verification gate to skip cryptographic validation entirely. This condition is intended to permit the use of the none algorithm, but it does so without ensuring that none is the only permitted algorithm in the configuration.

Analyzing the difference between the vulnerable codebase and the patched implementation highlights the exact logical gaps that enabled the bypass.

Vulnerable Logic in src/verifier.js

In the vulnerable implementation, the instantiation phase did not prevent a mismatch between algorithms and the presence of a real key:

// In vulnerable versions:
const keyType = typeof key
if (key && keyType !== 'function') {
  // Only executed if key is truthy.
  // This meant falsy keys skipped critical configuration safety gates.
  prepareKeyOrSecret()
}

During verification, the function evaluated the following:

// In verifyToken execution path:
const hasKey = !!this.key
const signature = token.signature
 
if (!hasKey && !signature) {
  // Bypasses the signature verification process entirely
  return token.payload
}

Patched Logic in src/verifier.js

The patch introduced in version 6.3.1 implements strict enforcement boundaries at instantiation time. It ensures that any falsy key configuration coupled with a non-none algorithm list causes the initialization to fail-closed immediately:

// Patched logic in version 6.3.1:
const keyType = typeof key
const allowsOnlyNone = allowedAlgorithms.length > 0 && allowedAlgorithms.every(algorithm => algorithm === 'none')
 
if (allowsOnlyNone) {
  if (key) {
    throw new TokenError(
      TokenError.codes.invalidOption,
      'The key option must not be provided when the only allowed algorithm is "none".'
    )
  }
} else if (keyType !== 'string' && keyType !== 'object' && keyType !== 'function') {
  throw new TokenError(
    TokenError.codes.invalidOption,
    'The key option must be a string, a buffer or a function returning the algorithm secret or public key.'
  )
} else if (!key && keyType !== 'function') {
  // Ensures a falsy key is rejected unless the only allowed algorithm is strictly 'none'
  throw new TokenError(
    TokenError.codes.invalidKey,
    'The key option is required unless the only allowed algorithm is "none".'
  )
}

By moving these checks to the instantiation boundary, fast-jwt prevents applications from deploying insecure verifier configurations that could silently permit signature bypasses.

Exploiting this vulnerability relies on an attacker constructing an unsigned JWT containing forged claims and delivering it to an application configured with a falsy secret key.

Attack Prerequisites

• The target application must initialize createVerifier with a dynamic key value that resolves to a falsy value (such as an empty string '' or null). This typically occurs when key configurations are loaded from uninitialized or missing environment variables.
• The verifier must be configured with an explicit list of allowed algorithms that does not enforce only 'none' (such as ['HS256']).

Payload Construction

JSON Web Tokens consist of three base64url-encoded parts separated by periods: the header, the payload, and the signature. An unsigned token contains an empty signature segment, resulting in a trailing period.

// Script to generate a forged unsigned token
const header = { alg: 'HS256', typ: 'JWT' };
const payload = { sub: 'admin', role: 'superuser', exp: Math.floor(Date.now() / 1000) + 3600 };
 
const encodedHeader = Buffer.from(JSON.stringify(header)).toString('base64url');
const encodedPayload = Buffer.from(JSON.stringify(payload)).toString('base64url');
 
// Construct the unsigned token (note the trailing period and absent signature)
const forgedToken = `${encodedHeader}.${encodedPayload}.`;
console.log(forgedToken);

When this token is presented to the vulnerable application, the system parses the empty signature, matches it against the uninitialized verifier, bypasses the cryptographic validation block, and processes the forged administrative claims.

The impact of this vulnerability is critical, representing a total compromise of the authentication and authorization layer of the target application. Successful exploitation permits complete authentication bypass, administrative privilege escalation, and unauthorized access to resources governed by the JWT validation mechanisms.

Because authentication tokens are typically used to convey user identities, access rights, and permission scopes, an attacker who can successfully bypass the signature check can impersonate any arbitrary identity within the application, including superusers or administrative staff.

The high attack complexity classification (AC:H) in the CVSS metric reflects the requirement that the target application must be configured with a falsy key option alongside an explicit list of allowed algorithms. However, in containerized or cloud-native environments where configuration keys are passed via dynamic environment variables, uninitialized environment variables can silently trigger this specific state, heightening the practical threat level.

Remediating this vulnerability requires immediate updates to the dependency tree of affected software and, where updates are delayed, implementing configuration verification.

Dependency Upgrades

To resolve the underlying issue permanently, upgrade the fast-jwt package to version 6.3.1 or newer. This version enforces strict checks during the verifier creation phase and raises a fatal exception if a falsy key is passed with signature-based algorithms.

npm install fast-jwt@6.3.1

Defense-in-Depth Configurations

Ensure that the environment variables or configuration files containing cryptographic secrets are strictly checked during the application bootstrapping process. If a secret is missing, empty, or undefined, the application must crash immediately rather than falling back to default values.

// Implement strict key checking on startup
const jwtSecret = process.env.JWT_SECRET;
if (!jwtSecret || jwtSecret.trim() === '') {
  throw new Error('FATAL: JWT_SECRET environment variable is missing or empty');
}

This defensive pattern prevents the application from entering a vulnerable operational state even if an older, vulnerable version of the library is active.