CVE-2026-120215 in fastify-cors
Summary
by MITRE • 11/02/2026
@fastify/cors is the CORS plugin for the Fastify web framework. In versions 8.2.0 through 11.3.x, an application that registers the plugin with the non-default onSend hook option crashes on a CORS preflight. On an OPTIONS request that carries the Origin and Access-Control-Request-Method headers, the plugin calls reply.send from inside the onSend hook and re-enters the send pipeline, so a second write of the response headers throws an uncaught ERR_HTTP_HEADERS_SENT that can terminate the Node.js process when no process-level handler is installed. An unauthenticated remote client can trigger this with a single preflight request, so the impact is availability only, and exploitation requires the non-default onSend configuration. The issue is fixed in @fastify/cors 11.4.0, where onSend is no longer an accepted hook value and registration fails with a clear error instead of crashing at request time, and users should upgrade to 11.4.0 or later. As a workaround, use any other hook such as the default onRequest, or set preflight to false.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/02/2026
The @fastify/cors plugin serves as a critical component for enabling Cross-Origin Resource Sharing in applications built on the Fastify web framework. In versions ranging from 8.2.0 through 11.3.x, a significant implementation flaw exists within how the plugin handles CORS preflight requests when configured with a non-default onSend hook option. This vulnerability stems from an incorrect interaction between the plugin's internal logic and Fastify's response pipeline mechanics. Specifically, during the handling of an OPTIONS request that includes standard CORS headers such as Origin and Access-Control-Request-Method, the plugin attempts to finalize the HTTP response by calling reply.send directly within the context of the onSend hook. This action inadvertently re-enters the send pipeline while it is already active for the same request object.
The technical consequence of this double-entry into the send pipeline is a critical state conflict where the system attempts to write HTTP headers that have already been sent or are in the process of being finalized by an outer layer of the framework's execution flow. This results in an uncaught ERR_HTTP_HEADERS_SENT error thrown by Node.js. Because this exception occurs within asynchronous code paths without proper local try-catch blocks, it propagates up the call stack and can terminate the entire Node.js process if no global unhandled rejection or uncaught exception handler is installed at the application level. This behavior classifies as a classic denial of service vulnerability where remote attackers do not need to inject malicious payloads but simply trigger specific request patterns that expose this race condition in state management.
From an operational impact perspective, this flaw allows any unauthenticated remote client to crash the server with a single preflight request. The availability of the web application is therefore compromised because each successful exploitation attempt results in process termination, requiring manual or automated restarts to restore service. While the vulnerability requires specific configuration conditions—namely the use of a non-default onSend hook—the ease of triggering it makes it particularly dangerous for applications that rely heavily on custom response hooks for logging, compression, or other middleware-like functionalities. The attack vector is straightforward and does not require authentication, making it accessible to any actor with network connectivity to the target service.
This issue aligns with CWE-400, which describes uncontrolled resource consumption leading to denial of service, as well as CWE-252 regarding unchecked return values that fail to handle error conditions properly within asynchronous flows. In terms of MITRE ATT&CK mapping, this vulnerability facilitates availability impact through exploitation of server-side logic errors, often categorized under techniques related to application layer attacks or specifically resource exhaustion via unhandled exceptions in web services. The lack of defensive coding practices around the hook execution context allows a simple HTTP request to escalate into a full system crash.
The resolution for this vulnerability was implemented in version 11.4.0 of @fastify/cors. In this updated release, the plugin no longer accepts onSend as a valid hook value during registration. Instead, it fails fast with a clear and descriptive error message at startup time if such an invalid configuration is detected. This approach prevents the runtime crash by ensuring that misconfigured applications fail to start rather than failing unpredictably under load or specific request patterns. Developers are strongly advised to upgrade to version 11.4.0 or later immediately upon deployment of this fix.
For organizations unable to upgrade immediately, a viable workaround involves modifying the Fastify hook configuration. Users should avoid using onSend for CORS-related logic and instead utilize other hooks such as onRequest, which executes earlier in the request lifecycle and does not suffer from the same pipeline re-entry issues. Alternatively, setting the preflight option to false can bypass the problematic code path entirely if CORS preflight handling is not required by the application architecture. These mitigations restore stability until a full upgrade to the patched version can be performed, ensuring that the service remains available against remote denial of service attempts exploiting this specific configuration flaw.