fastify vulnerable to Denial of Service via uncaught exception on handlerTimeout with streaming responses
Only affects fastify 5.8.0 up to 5.12.7 when handlerTimeout is nonzero and a route sends a streaming response that stays open past the timeout. Fixed in 5.12.8.
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
- Exploited
- No known exploitation
- Fix
- Fixed in 5.12.8
- Who is exposed
- Specific setups only
Do first: Check whether your setup matches what the bug needs. fastify versions >= 5.8.0 and < 5.12.8 are affected Server has a nonzero handlerTimeout configured A streaming response has already sent its headers and stays open past the timeout
- 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? →
- 18/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 5.12.8
- 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
Fastify, a Node.js web framework, is affected when a non-default handler timeout is enabled and a route sends a streaming response. A single unauthenticated request to such a route can crash the entire server process, interrupting all other in-flight requests and causing a denial of service.
Read the original description
fastify is a web framework for Node.js. In versions 5.8.0 through 5.12.7, when the server is configured with a nonzero handlerTimeout and a route returns a streaming response, a request whose stream has already sent its headers but stays open past the timeout crashes the server. When the timeout fires, Fastify tries to send a new error response on a response that has already started, raising an uncaught ERR_HTTP_HEADERS_SENT that terminates the Node.js process and interrupts any other in-flight requests. An unauthenticated remote client can trigger this with a single request to an affected streaming endpoint, so the impact is availability only, and exploitation requires the non-default handlerTimeout to be set. The default handlerTimeout of 0 is not affected. The issue is fixed in fastify 5.12.8, and users should upgrade to 5.12.8 or later. As a workaround, set handlerTimeout to 0, which disables the affected timeout path.
What to do
Check whether your setup matches what the bug needs.
fastify versions >= 5.8.0 and < 5.12.8 are affected Server has a nonzero handlerTimeout configured A streaming response has already sent its headers and stays open past the timeoutUpgrade to a fixed version: 5.12.8.
Workaround: Set handlerTimeout to 0, which disables the affected timeout path
Timeline
- CVE published
- First seen by cve.now
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: partial
- Record last updated
Affected versions
- fastify fastify
From 5.8.0 · fixed in 5.12.8
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-120216
What does this mean?
When a route streams a response and the handler timeout fires while the stream is still open after its headers were sent, fastify tries to send an error response that cannot be sent. This raises an uncaught ERR_HTTP_HEADERS_SENT exception that crashes the Node.js process and interrupts other in-flight requests.Source: github.com
Am I affected, and how do I check?
Fastify versions 5.8.0 up to but not including 5.12.8 are affected. The setup requires a nonzero handlerTimeout and a route that returns a streaming response; check the installed version with npm ls fastify and look for handlerTimeout in the server options.Source: github.com
What should I do about it?
Upgrade fastify to 5.12.8 or later. Until the upgrade is done, setting handlerTimeout to 0 disables the affected timeout path.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