CVE-2026-25224

What it actually does

Fastify versions prior to 5.7.3 can mishandle Web Streams returned through reply.send(), including ReadableStream objects or Response objects with a Web Stream body. When a client reads very slowly or stops reading, the affected response path can ignore backpressure and continue buffering response data in memory. A remote unauthenticated client can therefore cause excessive memory growth in the Node.js process, potentially leading to garbage-collection pressure, event-loop degradation, out-of-memory termination, container restarts, or service unavailability. The issue affects availability only; it does not directly enable code execution, data theft, or data modification.

Why it matters to the business

Public or internal services built on affected Fastify versions may become unstable or unavailable if exposed endpoints return Web Stream-based responses and a client intentionally consumes responses slowly. The practical impact is service degradation, elevated infrastructure resource consumption, failed requests, autoscaling churn, and possible outage conditions for APIs or web applications. The CVSS score and EPSS probability are low, it is not listed in CISA KEV, and no mature public exploitation is indicated, but internet-facing streaming endpoints should still be prioritized because denial-of-service flaws can be triggered without authentication when the vulnerable code path is reachable.

How an attack unfolds

An attacker first identifies an application using a vulnerable Fastify version and locates an endpoint that returns a ReadableStream or a Response with a Web Stream body through reply.send(). The attacker then opens one or more HTTP connections to that endpoint and deliberately reads the response very slowly, pauses reads, or otherwise causes the server-side socket to remain backpressured. In vulnerable versions, Fastify’s Web Streams response handling can continue producing or buffering data despite the client not consuming it. Over time, memory accumulates in the Node.js process. With enough duration, response size, or concurrent slow clients, the service may suffer high memory usage, frequent garbage collection, degraded latency, connection exhaustion, process crashes, or orchestrator-driven restarts. Because exploitation requires the vulnerable response pattern and sustained slow/non-reading behavior, attack complexity is higher than a simple one-shot request.

How to fix it

Upgrade Fastify to version 5.7.3 or later. For source-based deployments, ensure the code includes the upstream fix commit 49468eddb7c59e07fb95183afbf03498fccac99e. Rebuild and redeploy all applications that bundle or vendor Fastify, and verify lockfiles and container images no longer resolve to vulnerable Fastify versions. As interim mitigation, avoid returning Web Streams directly via reply.send() on affected versions, add strict request/response timeouts, enforce per-connection and per-IP concurrency limits, place services behind reverse proxies that limit slow clients, cap maximum response duration and size where feasible, and configure process/container memory limits with safe restart behavior. Network-layer slow-client protections in load balancers, reverse proxies, and API gateways can reduce exploitability but should not be treated as a substitute for upgrading.

How to confirm the fix worked

Confirm the deployed dependency version reports Fastify 5.7.3 or later, or verify the upstream fix commit 49468eddb7c59e07fb95183afbf03498fccac99e is present in source builds. Check package manifests, lockfiles, software composition analysis results, container image SBOMs, and runtime dependency output such as npm ls fastify. Identify routes that return ReadableStream objects or Response objects with Web Stream bodies through reply.send(), then perform controlled testing in a non-production environment using slow-reading clients while monitoring Node.js RSS/heap memory, garbage collection, event-loop delay, request latency, and process restarts. A fixed build should not show unbounded memory growth solely because a client reads a streamed response slowly.

Typical attack path

1. Identify Fastify-based services exposed over HTTP or HTTPS.
2. Fingerprint or infer Fastify usage and search for endpoints that return streamed content, large generated responses, file-like streams, or Web Stream-backed Response objects.
3. Open HTTP requests to vulnerable streaming endpoints.
4. Throttle response reads, stop reading from the socket, or keep connections open while consuming data extremely slowly.
5. Repeat across multiple concurrent connections to increase memory pressure.
6. Wait for the Node.js process to accumulate buffered response data, resulting in high memory usage, degraded performance, failed requests, or process termination.

How to detect it

To determine whether this issue was already exploited, correlate application, reverse proxy, load balancer, container, and host telemetry around periods of high memory use or service restarts. Look for long-lived HTTP requests to streaming or large-response endpoints where the response duration is high but bytes sent progress slowly, repeated client disconnects, upstream timeout events, broken pipe/socket hang-up errors, and many concurrent connections from the same source or network range. In Node.js and container telemetry, review spikes in RSS/heap memory, garbage-collection pauses, event-loop lag, OOMKilled events, process exits, and orchestrator restarts. Web server and proxy logs may show requests with unusually long request_time/upstream_response_time values, low body_bytes_sent relative to duration, HTTP 499/408/504 statuses, or connection reset events. Application logs may contain memory allocation failures or fatal JavaScript heap errors. There are no unique payload strings for this vulnerability; detection is behavioral and should focus on slow-client patterns targeting endpoints that return Web Streams via Fastify.

• JavaScript heap out of memory
• FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
• FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
• ENOMEM
• OOMKilled
• signal: killed
• socket hang up
• ECONNRESET
• EPIPE
• write EPIPE
• client prematurely closed connection
• upstream timed out
• request_time
• upstream_response_time
• body_bytes_sent
• HTTP 499
• HTTP 408
• HTTP 504
• ReadableStream
• reply.send(
• new Response(

What your security team should do

• Inventory applications and container images that use Fastify, especially version 5.x deployments below 5.7.3.
• Prioritize internet-facing APIs and services with endpoints that stream responses, generate large responses, or return Web Stream-backed Response objects.
• Upgrade Fastify to 5.7.3 or later and redeploy dependent services; verify lockfiles and SBOMs reflect the fixed version.
• Review Fastify route handlers for reply.send() usage with ReadableStream or Response Web Stream bodies and add tests covering slow-client behavior.
• Enable or tune reverse proxy, load balancer, and API gateway protections for slow clients, connection duration, idle timeouts, and per-source concurrency.
• Add monitoring and alerts for abnormal Node.js memory growth, out-of-memory kills, container restarts, elevated event-loop delay, and spikes in long-lived streaming responses.
• Review historical logs for slow or long-lived client connections to streaming endpoints during periods of memory pressure or unexplained restarts.
• Treat this as a moderate availability risk rather than an emergency mass-exploitation issue unless vulnerable streaming endpoints are publicly reachable or operational telemetry shows active abuse.