CVE-2025-32996

What it actually does

This is a denial-of-service flaw in http-proxy-middleware caused by request body handling logic that can invoke writeBody twice for the same proxied request because mutually exclusive branches were not implemented with an else-if structure. In affected versions, a crafted request that reaches a vulnerable proxy path can cause duplicate body writes, which may trigger Node.js stream or HTTP response errors, unhandled exceptions, worker crashes, request failures, or degraded proxy availability. The issue does not indicate remote code execution, privilege escalation, or direct data disclosure; the primary impact is service disruption in applications that expose affected proxy middleware behavior.

Why it matters to the business

Applications that rely on affected http-proxy-middleware versions may be susceptible to targeted or repeated requests that interrupt API gateway, development server, backend-for-frontend, or reverse-proxy functionality. The operational risk is moderate because the CVSS score is 4.0, EPSS is low at 0.00442, it is not listed in CISA KEV, and there is no known ransomware association or mature public exploitation signal in the provided data. However, because http-proxy-middleware is commonly embedded as a dependency in JavaScript services and tooling, unpatched instances can still cause outages, failed customer requests, noisy restarts, or cascading dependency failures if deployed on internet-facing or high-traffic proxy routes.

How an attack unfolds

An attacker first identifies an application or service that uses a vulnerable http-proxy-middleware version before 2.0.8 or a 3.x version before 3.0.4. The attacker then sends HTTP requests to a route handled by the middleware, shaping the request body, headers, or method so the vulnerable body-writing code path is reached. Because the vulnerable logic can call writeBody more than once for a single request, the application may attempt to write to an already-ended stream or otherwise violate Node.js HTTP response semantics. If the application does not safely catch and recover from the resulting exception, the worker process can terminate, restart, or stop serving requests. Repeating the request can sustain a denial of service against affected proxy endpoints. No named threat actors, KEV exploitation, or ransomware campaigns are indicated in the provided intelligence.

How to fix it

Upgrade http-proxy-middleware to a fixed release: use version 2.0.8 or later for the 2.x line, or version 3.0.4 or later for the 3.x line. If consuming directly from the upstream Git repository, ensure the fix including commit 01934d33b157b2d49f7099a18ceec165e7502040 is present. Rebuild and redeploy applications after updating lockfiles so transitive copies are replaced, and verify container images and serverless bundles do not retain older node_modules content. For Red Hat Enterprise Linux 7.7 extended streams listed in the input, apply vendor-provided updates at or beyond 0:3.10.0-1062.72.1.el7 for the listed kernel, bpftool, perf, and related packages where applicable. As interim mitigation, restrict access to vulnerable proxy routes, add rate limiting, enforce request size limits, improve process supervision, and configure Node.js applications to handle proxy middleware errors without crashing.

How to confirm the fix worked

Confirm dependency versions using package manager and software composition analysis outputs, such as npm ls http-proxy-middleware, yarn why http-proxy-middleware, pnpm why http-proxy-middleware, package-lock.json, yarn.lock, pnpm-lock.yaml, SBOMs, and container image scans. The application should show http-proxy-middleware 2.0.8 or later on the 2.x branch, or 3.0.4 or later on the 3.x branch. For Git-based installs, confirm the deployed source includes commit 01934d33b157b2d49f7099a18ceec165e7502040 or an equivalent patched change. For Red Hat-managed systems, validate installed package versions with rpm -q or yum updateinfo and confirm affected packages are at or above 0:3.10.0-1062.72.1.el7 where the vendor advisory applies. After patching, run integration tests against proxy routes that handle request bodies and confirm requests complete normally without duplicate-write, stream-write, or headers-sent errors. Also verify running containers, build artifacts, and deployed application bundles were rebuilt after the dependency update rather than only updating source repositories.

Typical attack path

1. Discover an HTTP endpoint that is implemented using http-proxy-middleware or a framework/tooling stack that embeds it.
2. Confirm that the reachable service is running http-proxy-middleware before 2.0.8 or 3.x before 3.0.4, or infer exposure from behavior and dependency fingerprints.
3. Send crafted proxied requests that exercise vulnerable request body handling logic.
4. Trigger duplicate writeBody execution for a single request, causing Node.js HTTP stream or response errors.
5. Cause the affected worker or process to fail, restart, or become unable to reliably proxy requests.
6. Repeat requests to prolong degraded availability or trigger recurring service disruption.

How to detect it

To assess prior exploitation, review application logs, reverse-proxy logs, process manager logs, container orchestration events, and APM/error telemetry for unexplained spikes in failed proxied requests, Node.js uncaught exceptions, worker restarts, HTTP 500/502/503 responses, or crash loops affecting routes handled by http-proxy-middleware. Useful sources include Node.js stdout/stderr, PM2 logs, systemd journal entries, Docker or Kubernetes container logs, ingress/load balancer access logs, WAF logs, and error monitoring platforms. Focus on time windows with repeated requests from the same source or small source set followed by errors such as write-after-end, headers already sent, unhandled stream errors, or stack traces referencing http-proxy-middleware body handling. Because no public exploit maturity, KEV listing, named threat actor use, ransomware association, or unique exploit payload is provided, detection should be behavior-based rather than relying on a highly specific signature. Correlate application restarts with HTTP request metadata such as method, path, body size, content type, status code, user agent, and source IP to distinguish active probing from normal application bugs.

• Error [ERR_STREAM_WRITE_AFTER_END]: write after end
• ERR_STREAM_WRITE_AFTER_END
• Error [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are sent to the client
• ERR_HTTP_HEADERS_SENT
• writeBody
• http-proxy-middleware
• node_modules/http-proxy-middleware
• uncaughtException
• UnhandledPromiseRejectionWarning
• PM2 log: App [
• systemd: Main process exited, code=exited
• CrashLoopBackOff

What your security team should do

• Inventory all JavaScript and Node.js applications, containers, CI build images, developer tooling, and backend services that include http-proxy-middleware directly or transitively.
• Prioritize patching internet-facing proxy routes, API gateways, backend-for-frontend services, and services with high availability requirements, even though current EPSS and exploitation maturity are low.
• Upgrade to http-proxy-middleware 2.0.8 or later, or 3.0.4 or later, and refresh lockfiles and deployed artifacts.
• Add temporary rate limits, request body size limits, and access controls around exposed proxy endpoints until patching is complete.
• Review application process supervision so Node.js worker crashes are restarted safely without causing full service outage, while still alerting on restart loops.
• Search logs for Node.js stream, duplicate-write, and process crash patterns around proxied HTTP routes to identify possible attempted exploitation or instability.
• Ensure SCA, SBOM, and container scanning rules flag http-proxy-middleware versions below 2.0.8 on 2.x and below 3.0.4 on 3.x.
• For vendor-managed Linux packages listed as affected, apply the corresponding Red Hat updates and verify installed versions meet or exceed the fixed package version.