---
id: "CVE-2026-120216"
kind: "vulnerability"
aliases: ["CVE-2026-120216"]
title: "Fastify: slow streaming responses crash the Node.js process after a timeout"
severity: "medium"
cvss: 5.9
epss: null
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["fastify", "node.js", "package", "self-hosted", "web-api"]
not_affected_if: ["default-config", "fastify-5.12.8-or-later", "fastify-below-5.8.0", "no-streaming-routes"]
published_at: "2026-11-02T11:17:31+00:00"
first_seen_at: "2026-11-02T11:22:54+00:00"
updated_at: "2026-11-02T11:24:16+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-120216", "first_seen_at": "2026-11-02T11:22:54+00:00"}]
---

# Fastify: slow streaming responses crash the Node.js process after a timeout

Fastify, a Node.js web framework, crashes the whole server process when a streaming response stays open past the configured handlerTimeout. An unauthenticated remote client can take the server down with a single request, interrupting other in-flight requests.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check the installed Fastify version with `npm ls fastify` and look for versions from `5.8.0` through `5.12.7`.
- Search the server configuration for `handlerTimeout` and confirm whether it is set to a nonzero value.
- Look for routes that return streaming responses.

## Fix

- fastify: upgrade to `5.12.8` or later
- Workaround stated in the sources: set `handlerTimeout` to `0`

## Timeline

- 2026-11-02T11:22:54+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-120216

## Documents

- [advisory] Vendor advisory: github.com https://github.com/fastify/fastify/security/advisories/GHSA-3qgw-9275-xf8w

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_