CVE-2026-55602: http-proxy-middleware Host+Path Routing Bypass (CVSS 8.6)

Technical summary

The vulnerability stems from improper input validation in http-proxy-middleware's host+path routing logic. When a proxy table is configured with host+path selectors (e.g., 'example.com/api'), the library is documented to match both host and path components. However, the implementation uses unanchored substring matching on the Host header rather than anchored or exact matching. For example, a request with Host header 'example.com.attacker.com' would match a rule configured for 'example.com' because the substring 'example.com' is present. This allows an attacker to craft a superstring of the expected hostname and reach backends that should only be accessible via the legitimate hostname. The root cause involves CWE-187 (Partial String Comparison) and CWE-20 (Improper Input Validation), enabling host confusion attacks. Fixed versions enforce proper anchored matching: 2.0.10, 3.0.6, and 4.1.0.

Business impact

Organizations running vulnerable versions of http-proxy-middleware face routing misconfiguration risks that could result in: (1) unintended exposure of internal backend services meant to be restricted to specific hostnames, (2) data breaches if a crafted request bypasses authentication or segmentation controls, (3) service disruption if an attacker routes traffic to a non-existent or overloaded backend, and (4) lateral movement within microservice architectures where backend services trust the proxy's routing decisions. The impact severity depends on the sensitivity of exposed backends and whether the application layer applies additional access controls.

Affected systems

The vulnerability affects http-proxy-middleware versions 0.16.0 through 2.0.9 (in the 2.x line), 3.0.5 (in the 3.x line), and all versions of 4.0.x (in the 4.x line). Any Node.js application using this library to proxy requests with host+path configuration is at risk. This includes API gateways, reverse proxies, and microservice orchestration layers that rely on http-proxy-middleware for dynamic request routing.

Exploitability

Exploitability is high. The attack requires no authentication, no special privileges, and no user interaction—only the ability to send an HTTP request with a crafted Host header. The flaw is trivial to exploit: an attacker simply appends characters to a known configured hostname (e.g., 'legit.com' becomes 'legit.com.attacker.com') and sends a request. No complex payload, code execution, or timing is needed. Networks accessible to untrusted users (internet-facing proxies) present the highest risk. The vulnerability has not been designated as widely exploited in public KEV databases at publication time, but the simplicity of the attack vector makes it likely to be weaponized once awareness increases.

Remediation

Upgrade http-proxy-middleware to a patched version immediately: version 2.0.10 or later (for the 2.x branch), 3.0.6 or later (for the 3.x branch), or 4.1.0 or later (for the 4.x branch). No workarounds exist short of upgrading or implementing additional request validation at the application layer. Organizations should verify that their dependency pinning or lock files are updated to pull the fixed versions during next deployment.

Patch guidance

1. Audit your package.json and lock files (package-lock.json or yarn.lock) to identify the current http-proxy-middleware version. 2. Update to 2.0.10+, 3.0.6+, or 4.1.0+ depending on your version line—do not skip to a different major version without testing. 3. Run npm audit to confirm the vulnerability is resolved. 4. Test your proxy routing configuration in a staging environment to ensure no legitimate traffic is affected by the stricter matching logic. 5. Deploy to production and monitor proxy logs for any routing anomalies in the days following deployment.

Detection guidance

In proxy logs, look for Host headers that contain the configured hostname as a substring but with additional domain segments (e.g., requests to 'example.com.attacker.com' when the proxy is configured for 'example.com'). Network-level detection can be implemented by monitoring for Host headers that do not exactly match configured upstream hostnames. Intrusion detection signatures should flag requests whose Host header contains a legitimate hostname suffix followed by additional dots or characters. Endpoint Detection and Response (EDR) tools can monitor Node.js process behavior for unexpected outbound connections to backends that deviate from configured routes.

Why prioritize this

This vulnerability scores 8.6 (HIGH) due to network-accessible attack surface (AV:N), low complexity (AC:L), no authentication requirement (PR:N), and high integrity impact (I:H). The scope change (S:C) reflects potential cross-boundary impacts in multi-tenant or microservice environments. While not yet exploited widely in the wild, the simplicity of the attack and the fact that http-proxy-middleware is a foundational library for many Node.js applications elevates the risk. Internet-facing proxies should be patched within 48–72 hours; internal proxies should follow within 2 weeks.

Risk score, explained

The CVSS 3.1 score of 8.6 reflects: (1) Network accessibility with no authentication barrier, (2) Deterministic, low-complexity exploitation via header manipulation, (3) High integrity impact—an attacker can cause requests to be routed to unintended backends, violating the security assumption of the proxy configuration, and (4) Scope change because compromised routing can affect downstream services or multi-tenant isolation. Confidentiality impact is scored as None because the vulnerability does not directly expose data; however, routing to an unintended backend may expose sensitive information if that backend lacks its own access controls, which is why business impact emphasizes data breach risk.

Frequently asked questions