Fastify CVE-2026-120216

Exploitation requires the server to be configured with a nonzero handlerTimeout (the non-default value) AND at least one route that returns a streaming response; the attacker sends a request to that streaming endpoint, lets it transmit headers, then holds the stream open until the timeout fires. Limiting factors: the default handlerTimeout of 0 is completely unaffected, so only applications that explicitly set a nonzero handlerTimeout on streaming routes are exposed; no authentication is required (PR:N) and no user interaction is needed, but the vulnerable configuration is not the default, which substantially reduces the realistic attack surface. Impact is availability-only (full process crash and interruption of concurrent requests); upgrading to fastify 5.12.8 is the fix, or setting handlerTimeout to 0 disables the affected timeout path as a workaround.

This is a moderate, conditional availability vulnerability rather than a top-tier emergency, and the signals are consistent in pointing that way. The supplied CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H, 5.9) correctly captures network reach by an unauthenticated client (PR:N) with impact limited to availability (C:N/I:N/A:H); the AC:H reflects the non-default precondition rather than any attacker-side timing trick, since the available sources do not describe a race or uncontrolled condition. The priority signal is Decision label 'this_month' (not act_now/emergency). KEV status is NO (not CISA-listed), there is no public exploit identified, and no EPSS score was provided in the input, so exploitation-probability cannot be quantified from this data. The single most important caveat, confirmed by both the NVD description and the GHSA advisory, is that exploitation requires a non-default configuration: a nonzero handlerTimeout AND a route that returns a streaming response. The default handlerTimeout of 0 is explicitly not affected, which sharply narrows the real-world exposed population. Net: a real, fixable DoS worth patching this month for teams that set handlerTimeout on streaming routes, but not a drop-everything issue given the config dependency, availability-only impact, absence of KEV/POC, and no EPSS to suggest widespread opportunistic exploitation.

An application running fastify 5.8.0-5.12.7 is configured with a nonzero handlerTimeout and exposes a streaming endpoint. An unauthenticated remote client sends a single request to that endpoint and keeps the connection open past the timeout after headers have already been sent; when the timeout fires, Fastify tries to emit a fresh error response on an already-started response, raising an uncaught ERR_HTTP_HEADERS_SENT that crashes the Node.js process and drops all other in-flight requests. No public exploit code or PoC reference was provided in the input.