@fastify/cors CVE-2026-120215

Exploitation requires the target application to register @fastify/cors with the non-default hook: 'onSend' option while preflight remains enabled (the default). Only that configuration is affected; the default onRequest hook and any deployment with preflight: false are not. Process termination additionally requires that no process-level uncaughtException handler is installed to swallow the error. Key limiting factors: the vulnerable mode is non-default and, per the vendor, preflighted CORS never functioned in that configuration, so affected applications were already broken for preflight - narrowing the real-world exposure considerably despite the unauthenticated, single-request trigger. The fix in 11.4.0 removes onSend as an accepted hook value entirely, failing registration with a clear error instead of crashing at request time; the vendor states upgrading is the remedy, with workarounds being any other hook (e.g. the default onRequest) or setting preflight: false.

This is a low-priority, high-noise-floor issue rather than an urgent threat, and the signals are internally consistent. The vendor CVSS of 3.7 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L) correctly reflects an availability-only denial of service: no confidentiality or integrity impact, and AC:H encodes that exploitation depends on a non-default configuration the attacker cannot influence. The vuln.today decision label is 'monitor,' the weakest urgency tier. No EPSS score is provided, so exploitation probability cannot be quantified from this data. KEV status is not indicated (not CISA-listed), and no public exploit or PoC reference is present - the two references are the GHSA advisory and the OpenJSF CNA page, which are advisories, not exploit code. The one point worth flagging is the AV:N/PR:N combination: while the network/unauthenticated metrics are real (a single preflight OPTIONS request from any remote client triggers the crash), the AC:H gate is doing heavy lifting - the flaw only manifests in applications explicitly registered with the non-default hook: 'onSend' option, and the advisory notes preflighted CORS never worked in that mode, so affected deployments were already non-functional for that path. Net: a genuine but narrow DoS affecting a small, misconfigured subset of deployments; prioritize routine patching, not emergency response.

A remote, unauthenticated attacker sends a single CORS preflight - an OPTIONS request carrying Origin and Access-Control-Request-Method headers - to a Fastify application that registered @fastify/cors with the non-default hook: 'onSend' option. The plugin calls reply.send() from within the onSend hook, re-entering the send pipeline; the second writeHead throws ERR_HTTP_HEADERS_SENT as an uncaught exception, terminating the Node.js process if no process-level handler is installed. No public exploit code is identified, but the trigger is trivial to craft from the advisory description.