CVE-2026-55602

What it actually does

CVE-2026-55602 is an improper input validation flaw in chimurai http-proxy-middleware affecting versions from 0.16.0 up to the fixed releases 2.0.10, 3.0.6, and 4.1.0. The vulnerable router logic treats configured host+path proxy-table entries as substring matches against attacker-controlled request metadata rather than enforcing an anchored, exact host match combined with the intended path match. A remote unauthenticated attacker can craft a Host header that contains a configured host+path selector as a superstring, causing the middleware to route the request to an unintended backend. The primary technical consequence is proxy routing confusion, which can lead to unauthorized access to internal services, bypass of intended routing controls, or integrity-impacting interactions with backends that were not meant to receive the request.

Why it matters to the business

Applications using affected versions of http-proxy-middleware may unintentionally expose or route traffic to backend services that operators believed were isolated behind host-and-path routing rules. In business terms, this can result in unauthorized access to administrative, internal, staging, tenant-specific, or service-to-service endpoints, potentially causing data exposure, unintended transactions, or disruption of application trust boundaries. The CVSS score of 8.6 reflects that exploitation is network-accessible, low-complexity, unauthenticated, and requires no user interaction. Although EPSS is currently low at 0.0037, the package is commonly used in Node.js proxy and development-server stacks, so organizations should prioritize review where it fronts sensitive backends or relies on Host-based routing for access separation.

How an attack unfolds

An attacker first identifies an application or gateway using http-proxy-middleware with router proxy-table entries that combine host and path selectors. They then infer or guess a configured host+path key, such as a virtual host and route prefix intended to map to a protected backend. Instead of sending a normal Host header that exactly matches the configured host, the attacker sends a crafted Host header containing the expected host value as a substring with attacker-controlled extra characters before or after it, while also requesting the matching path. Because vulnerable versions perform unanchored substring matching, the request may satisfy the router condition even though the Host value is not the intended hostname. The middleware then forwards the request to a backend that should not have been selected for that external request, allowing the attacker to interact with unintended internal routes or services depending on the proxy configuration and backend authorization controls.

How to fix it

Upgrade http-proxy-middleware to a fixed release appropriate for the major version in use: 2.0.10, 3.0.6, or 4.1.0 or later. Review package-lock.json, yarn.lock, pnpm-lock.yaml, container images, and bundled application dependencies to ensure no vulnerable transitive or pinned versions from 0.16.0 through the unfixed releases remain. If immediate upgrade is not possible, avoid relying on host+path router entries for security-sensitive separation, enforce exact Host header validation before the middleware processes requests, reject malformed or unexpected Host values at the edge proxy or load balancer, and add explicit backend authorization checks independent of proxy routing. Normalize and validate Host headers using an allowlist of exact hostnames, and ensure upstream proxies do not pass ambiguous or attacker-controlled host metadata into routing logic.

How to confirm the fix worked

Confirm the installed http-proxy-middleware version is 2.0.10, 3.0.6, 4.1.0, or later using package manager inventory commands and lockfile inspection. Validate runtime containers and built artifacts, not only source repositories, because vulnerable versions may remain in deployed images. Functionally test affected proxy routes by sending requests with an expected valid host and path, then repeat with Host values that contain the valid hostname as a prefix, suffix, or embedded substring with extra characters. A fixed or mitigated deployment should reject the malformed Host header or avoid routing it to the protected backend. Also confirm edge proxies, CDN rules, ingress controllers, and application middleware enforce exact expected Host values before requests reach http-proxy-middleware.

Typical attack path

1. Locate a Node.js application, API gateway, development server, or reverse proxy that uses http-proxy-middleware.
2. Probe application behavior with different Host headers and paths to identify Host-based routing decisions.
3. Infer or discover a configured host+path router entry that maps to a sensitive or unintended backend.
4. Send a request using a crafted Host header that contains the expected host value as an unanchored substring rather than an exact hostname.
5. Include the matching path component so the vulnerable router selects the unintended backend.
6. Interact with the incorrectly routed backend endpoint to access data, invoke functions, or bypass intended routing boundaries.

How to detect it

To assess whether exploitation already occurred, review HTTP access logs from edge proxies, load balancers, application servers, and Node.js middleware for requests where the Host header is not an exact expected hostname but contains a legitimate configured hostname as a substring. Focus on requests to paths that are mapped by http-proxy-middleware router proxy-table entries, especially administrative, internal API, staging, callback, or service-to-service paths. Compare logged Host headers against the application’s configured allowed hostnames and flag prefix, suffix, embedded, mixed-case, punycode, port-suffixed, or otherwise malformed variants that still reached backend routes. Correlate suspicious requests with backend access logs to determine whether unintended services received traffic from the proxy. Look for unexpected response codes from sensitive paths, unusual backend selection, requests with external client IPs reaching internal-only routes, and anomalies in X-Forwarded-Host, X-Forwarded-For, Forwarded, and original Host metadata. If request routing decisions are logged, search for cases where the selected target backend does not correspond to an exact Host match. There are no known public exploit-specific payload strings or malware indicators for this CVE based on the provided information, so detection should be behavior- and configuration-driven.

What your security team should do

• Inventory all Node.js applications and proxy components using chimurai http-proxy-middleware, including transitive dependencies and development-server configurations exposed beyond localhost.
• Prioritize upgrades for internet-facing applications, API gateways, reverse proxies, admin consoles, multi-tenant services, and any deployment where Host-based routing separates sensitive backends.
• Upgrade to http-proxy-middleware 2.0.10, 3.0.6, 4.1.0, or later, and redeploy affected containers or serverless bundles.
• Add exact Host header allowlisting at the earliest ingress layer and reject Host values that are not explicitly expected.
• Review router proxy-table configurations that use host+path selectors and determine whether unintended backends could have been reached.
• Search historical access logs for unusual Host headers containing legitimate hostnames with additional leading or trailing characters, especially on sensitive paths.
• Ensure backend services enforce their own authentication and authorization rather than relying solely on proxy routing decisions.
• Add regression tests for proxy routing rules to verify that superstring Host values do not match configured host+path routes.