GHSA-6x33-pw7p-hmpq

What it actually does

Affected versions of the npm package http-proxy before 1.18.1 can be driven into a denial-of-service condition when handling specially crafted or malformed HTTP traffic. In vulnerable applications that embed http-proxy as a reverse proxy, development proxy, gateway, or middleware component, the library may raise an unhandled exception or error event during request processing. If the hosting Node.js process does not defensively catch the failure, the process can terminate, making the proxied service unavailable until it is restarted. The impact is availability-only; the advisory does not indicate data disclosure, authentication bypass, or code execution.

Why it matters to the business

Successful exploitation can take an application, API gateway, or proxy-dependent service offline, causing user-facing outages, failed transactions, degraded availability, and operational noise from repeated restarts. Because this vulnerability was published in 2020 and fixed in http-proxy 1.18.1, continued exposure generally indicates an outdated dependency or transitive dependency that should be remediated as part of dependency hygiene. It is not listed in CISA KEV and no ransomware use is indicated in the provided data, but internet-exposed proxy functionality should still be prioritized because the attack can be performed remotely and does not require authentication.

How an attack unfolds

An attacker first identifies an application endpoint backed by a Node.js service using a vulnerable version of http-proxy. The attacker sends malformed, abnormal, or intentionally disruptive HTTP requests to the proxy-facing endpoint. When the vulnerable library attempts to parse, transform, or forward the request, it can encounter an error path that is not safely handled. In deployments where the application does not attach robust error handlers or where the process manager treats the exception as fatal, the Node.js process exits or becomes unavailable. The attacker can then repeat the request pattern to keep the service in a crash loop, turning a single library-level bug into a sustained application outage.

How to fix it

Upgrade http-proxy to version 1.18.1 or later. For npm-based projects, update direct dependencies in package.json and regenerate the lockfile, then redeploy rebuilt artifacts. If http-proxy is present transitively, identify the parent package with `npm ls http-proxy` and upgrade the parent dependency to a version that resolves to http-proxy 1.18.1 or later. Where immediate upgrade is not possible, add defensive error handling around proxy instances, ensure `error` events are handled, place the service behind a reverse proxy or WAF that rejects malformed HTTP traffic, apply rate limiting, and configure the process manager to restart failed workers while the permanent dependency fix is prepared. The fixed version provided is: http-proxy (npm) fixed in 1.18.1.

How to confirm the fix worked

Confirm that no deployed artifact resolves to http-proxy below 1.18.1 by checking package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, SBOMs, and container image contents. Run `npm ls http-proxy` in built application trees and verify the resolved version is 1.18.1 or later. In staging, send malformed and abruptly terminated HTTP requests representative of the expected edge cases and confirm the service returns controlled 4xx/5xx responses or closes the connection without process termination. Validate that Node.js process uptime remains stable, no uncaught exceptions referencing http-proxy are emitted, and health checks continue to pass under negative testing.

Typical attack path

1. Discover an internet-facing or network-accessible service that behaves like a Node.js reverse proxy or gateway.
2. Send crafted malformed HTTP requests or abnormal connection patterns to the proxy endpoint.
3. Trigger an unhandled error path inside the vulnerable http-proxy request-handling logic.
4. Cause the Node.js process, worker, or container to crash or restart.
5. Repeat the request sequence to maintain denial of service and prevent stable recovery.

How to detect it

To determine whether exploitation already occurred, correlate ingress logs, WAF logs, load balancer logs, application logs, and process supervisor events. Look for sudden Node.js worker exits, container restarts, or health-check failures immediately after malformed HTTP requests, unusual request-line syntax, invalid headers, abrupt client disconnects, or repeated requests from the same source that result in 400, 408, 499, 500, or 502 responses. Application logs may show uncaught exceptions, unhandled error events, or stack traces referencing node_modules/http-proxy shortly before process termination. Also review PM2, systemd, Kubernetes, Docker, and orchestration events for crash-loop patterns that align with suspicious inbound HTTP traffic. Because this is a denial-of-service issue rather than a persistence or code-execution flaw, durable host artifacts may be limited; the strongest evidence is timing correlation between malformed traffic and proxy process crashes.

• node_modules/http-proxy
• Unhandled 'error' event
• uncaughtException
• node_modules/http-proxy/lib/http-proxy/passes/web-incoming.js
• node_modules/http-proxy/lib/http-proxy/index.js
• socket hang up
• ECONNRESET
• HPE_INVALID_HEADER_TOKEN
• HPE_INVALID_METHOD
• HPE_INVALID_URL
• CrashLoopBackOff
• npm ls http-proxy

What your security team should do

• Inventory applications, containers, and build artifacts that include the npm package http-proxy, including transitive dependency usage.
• Prioritize internet-facing reverse proxies, API gateways, developer proxies exposed outside trusted networks, and services without redundant worker/process isolation.
• Upgrade all affected deployments to http-proxy 1.18.1 or later and rebuild from a clean lockfile.
• Add or verify application-level proxy error handlers so unexpected upstream, downstream, or malformed request errors do not terminate the process.
• Enable rate limiting and malformed HTTP request filtering at the edge for services that proxy untrusted traffic.
• Review process supervisor, Kubernetes, PM2, systemd, and container restart logs for historical crash loops correlated with malformed HTTP traffic.
• Add dependency scanning gates to CI/CD so vulnerable http-proxy versions cannot be reintroduced.