CVE-2026-120216: fastify vulnerable to Denial of Service via uncaught exception on handlerTimeout with streaming responses

Published Nov 2, 2026
·
Updated

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 ERRHTTPHEADERSSENT 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.

Event History

Nov 2, 2026
CVE Published
via OSV·11:08 AM
Data Sourced
via OSV·11:08 AM
DescriptionSeverityWeakness
Data Sourced
via NVD·11:17 AM
DescriptionSeverityWeakness

Frequently Asked Questions

1

Which deployments are exposed to this denial-of-service condition?

Deployments using Fastify versions 5.8.0 through 5.12.7 are exposed only if handlerTimeout is configured to a nonzero value and at least one route returns a streaming response. The default handlerTimeout value of 0 is not affected.

2

What does an attacker need to do to trigger the crash?

An unauthenticated remote client needs to make a request to an affected streaming endpoint and keep the stream open after it has sent headers until handlerTimeout expires. A single such request can terminate the Node.js process and interrupt other in-flight requests.

3

What mitigation is available if upgrading is not immediately possible?

Set handlerTimeout to 0 to disable the affected timeout path. This removes the condition that causes Fastify to attempt sending an error response after streaming response headers have already been sent.

4

What version fixes the issue?

Upgrade Fastify to version 5.12.8 or later.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203