@fastify/cors vulnerable to Denial of Service on a CORS preflight with the onSend hook
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
- Exploited
- No known exploitation
- Fix
- Fixed in 11.4.0
- Who is exposed
- Specific setups only
Do first: Check whether your setup matches what the bug needs. @fastify/cors is registered with the non-default hook option set to 'onSend' Preflight is enabled (the default setting) Affected @fastify/cors versions are 8.2.0 up to but not including 11.4.0
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- Published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 16/100 · provisional
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Specific setups only
- Fix
- Fixed in 11.4.0
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: partial
Summary
The @fastify/cors plugin for the Fastify Node.js web framework can be crashed by a single unauthenticated CORS preflight request when it is configured with the non-default onSend hook option. The result is a denial of service, since the Node.js process can terminate.
Read the original description
@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.
What to do
Check whether your setup matches what the bug needs.
@fastify/cors is registered with the non-default hook option set to 'onSend' Preflight is enabled (the default setting) Affected @fastify/cors versions are 8.2.0 up to but not including 11.4.0Upgrade to a fixed version: 11.4.0.
Workaround: Use any other hook such as the default onRequest, or set preflight to false
Timeline
- CVE published
- First seen by cve.now
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: partial
- Record last updated
Affected versions
- @fastify/cors @fastify/cors
From 8.2.0 · fixed in 11.4.0
Evidence 2
- Advisory
- Link
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-120215
What does this mean?
A crafted CORS preflight request can make a Node.js process crash when @fastify/cors is registered with the non-default hook option set to 'onSend'. The error escapes as an uncaught exception, which ends the process if no process-level uncaught exception handler is installed.Source: github.com
Am I affected, and how do I check?
Affected are @fastify/cors versions from 8.2.0 up to but not including 11.4.0, and only when hook is set to 'onSend' with preflight enabled, which is the default. To check, look at the installed @fastify/cors version in package.json or with npm ls @fastify/cors, and check whether the hook option passed to the plugin is 'onSend'.Source: github.com
What should I do about it?
Upgrade @fastify/cors to 11.4.0 or later. Until then, switching to another hook such as the default onRequest, or setting preflight to false, avoids the crash.Source: github.com
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data