CVE-2026-84504: Schema Validation Bypass via Async Validation Result Collision in Fastify

The Fastify web framework relies on an internal validation runner to parse and validate incoming client requests. This component compiles route-specific schemas to sanitize input before the payload reaches downstream application controllers. Under default conditions, this architecture prevents malicious or malformed data from causing type confusion, parameter injection, or logic flaws within handlers.

To accommodate a wide ecosystem of custom schema compilers, Fastify supports both synchronous and asynchronous validation interfaces. Synchronous compilers, such as Joi, return structured validation results inside an envelope object. In contrast, asynchronous compilers, such as Ajv when compiled with the $async: true directive, resolve directly with the successfully validated dataset rather than an envelope.

This architectural difference creates a critical attack surface within the request runner. When processing successful asynchronous resolutions, the framework's internal runner fails to isolate the raw validated payload from legacy synchronous envelope-parsing rules. Consequently, attackers can transmit structured payloads that deliberately collide with internal validation properties, resulting in complete validation bypass.

The core of the vulnerability lies in the legacy unwrapping function named answer() in Fastify's validation execution path. This function is designed to handle custom synchronous validators that return a metadata wrapper structured as { value, error }. If answer() detects an error key on its argument, it signals a validation failure, whereas if it detects a value key, it extracts the nested value to replace the current request.body object.

When a route uses an asynchronous validation compiler, the validator returns a Promise that resolves directly with the raw validated payload upon success. The validation runner handles this resolved payload by passing it straight into the legacy answer() wrapper function. This creates an unhandled type collision because the user-controlled, successfully validated request payload is now evaluated as if it were a synchronous compiler envelope.

If an attacker structures an input payload to contain a root-level property named value, the asynchronous schema validator verifies that the outer object meets the schema criteria and passes the object to the resolver. The runner then processes this validated object through answer(). Because the object contains a root-level value property, answer() extracts its nested contents and assigns them directly to request.body, bypassing all structural checks on the nested fields.

The flaw is located in lib/validation.js where asynchronous validation promises are resolved and returned to the request lifecycle. The vulnerable path executes answer(res) on the resolved data, assuming it represents a validation wrapper.

Below is the code comparison between the vulnerable implementation and the patch:

// === VULNERABLE CODE ===
if (ret && typeof ret.then === 'function') {
  return ret
    .then((res) => { return answer(res) }) // Vulnerable wrapper processing
    .catch(err => { return err })
}
 
// === PATCHED CODE ===
if (ret && typeof ret.then === 'function') {
  // An async validator resolves with the validated data itself,
  // not a { value, error } result envelope. Its properties must
  // not be unwrapped. Treat the async result as pass/fail only.
  return ret
    .then((res) => { return res === false ? validatorFunction.errors : false })
    .catch(err => { return err })
}

In the patched version, the call to answer() is eliminated from the promise resolution chain. The runner now evaluates the resolved promise solely as a indicator of validation success or failure. If res is strictly false, validation is treated as failed and errors are returned. Otherwise, it returns false to indicate that no validation errors occurred, completely bypassing the legacy unwrapping logic.

To exploit this vulnerability, an attacker must identify a route that utilizes an asynchronous JSON Schema compiler, such as Ajv with asynchronous schemas. The endpoint must also permit additional properties on the input schema, or specifically permit a root-level parameter named value.

The exploit payload is structured with a root-level value property containing arbitrary, unvalidated keys. When submitted, the validator verifies only the top-level keys. Upon validation success, Fastify extracts the contents of value and promotes them to the root of request.body. This mechanism completely evades schema enforcement, allowing the injection of forbidden configuration properties, administrative roles, or restricted identifiers.

The impact of this vulnerability is classified as high severity with a CVSS v3.1 score of 8.1. By systematically bypassing JSON schema validation, remote attackers can achieve parameter injection, unauthorized modification of application state, and type confusion in backend databases or business logic.

In typical production applications, schema validation serves as the primary barrier against privilege escalation. For example, if a profile update route forbids the role parameter via schema constraints, an attacker can bypass this restriction by passing { "username": "user", "value": { "role": "admin" } }. This allows the attacker to gain administrative capabilities, modify access controls, or corrupt data integrity.

Furthermore, because the newly substituted request body never undergoes validation, database insertion operations may receive unexpected data structures. This can trigger unexpected application crashes, unhandled database exceptions, or secondary SQL injection and NoSQL injection vulnerabilities in downstream logic.

The primary remediation for this vulnerability is to upgrade Fastify to version 5.12.2 or later, which completely decouples the asynchronous execution path from the legacy synchronous unwrapping logic.

If immediate upgrading is not feasible, developers should enforce additionalProperties: false on all routes employing asynchronous validation. This configuration forces the schema validator to reject any payloads containing the unexpected root-level value property before the validation runner processes the result.

Alternatively, a global preValidation hook can be integrated to detect and drop payloads containing root-level value or error keys on affected routes. This ensures that potentially malicious collision payloads are discarded at the beginning of the request lifecycle.