CVE-2026-55602: http-proxy-middleware router Host-Header Routing Bypass

On June 22, 2026, GitHub disclosed CVE-2026-55602 (GHSA-64mm-vxmg-q3vj), an improper input validation flaw in the Node.js package http-proxy-middleware. It affects every release from 0.16.0 up to the fixed 2.0.10, 3.0.6, and 4.1.0 lines. The GitHub CNA scored it 6.9 Medium on CVSS v4 (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N); NVD analyzed it separately and scored it 8.6 High on CVSS v3.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N). The bug (CWE-20 / CWE-187) is in the router proxy-table: the host+path selector uses an unanchored substring match on the attacker-controlled Host header, so a Host value that merely contains a configured key as a substring still routes to that key's backend. No authentication is required. The maintained 2.x, 3.x, and 4.x lines have upstream fixes. Older lines like 0.19.x, still pulled in transitively by legacy build tooling, have no OSS fix available.

Affected and unsupported? See NES for http-proxy-middleware (part of HeroDevs Web Essentials).

‍

What is http-proxy-middleware, and why do old versions stick around?

http-proxy-middleware is a Node.js HTTP proxy middleware for Connect, Express, browser-sync, and similar frameworks, built on top of the http-proxy library. You give it a target (or a table of targets) and it forwards matching requests to the appropriate backend. It is one of the quietest, most load-bearing packages in the JavaScript ecosystem: roughly 25 million downloads a week, and most people never install it directly.

That last point is the whole story for why this CVE matters years after the affected code shipped. The package is almost always a transitive dependency, dragged in by dev servers and build tooling rather than chosen by the application author. And the old lines are still everywhere:

• The 2.x line is 61% of weekly downloads. webpack-dev-server 4.x pins http-proxy-middleware at ^2.0.3, so any project on webpack 5 tooling is on the 2.x line whether it knows it or not.
• The 0.19.x line is still ~1.7M downloads a week. webpack-dev-server 3.11.x, the version that ships with the Angular CLI v9-era toolchain and older Create React App setups, pins http-proxy-middleware at exactly 0.19.1. Projects frozen on those toolchains cannot move off 0.19.x without a build-tooling migration they have usually been avoiding for a reason.

So you get the classic EOL trap. The vulnerable code is in a package you did not choose, on a version line you cannot bump without upgrading the tool that pins it, in a toolchain you froze because upgrading it breaks your app. The upstream fix exists for the maintained lines, but if you are on 0.19.x because webpack-dev-server 3.x put you there, "just upgrade" means a webpack and framework migration, not a one-line dependency bump.

‍

What is CVE-2026-55602?

CVE-2026-55602 is an improper input validation vulnerability (CWE-20), with a more specific match to CWE-187 (partial comparison). It lives in the router feature, the documented proxy-table that lets you route requests to different backends based on the incoming host, path, or combined host+path.

The documentation describes host+path keys as exact selectors. The implementation does not treat them that way. Internally, getTargetFromProxyTable() concatenates the request's Host header and path, then checks whether any configured proxy-table key appears as a substring of that concatenation. Because the match is unanchored, a request whose host+path merely contains a configured key still matches it.

Here is the concrete case from the advisory. Given a proxy table like { 'localhost:3000/api': 'http://alt-backend' }, a request arriving with Host: evillocalhost:3000 and path /api concatenates to evillocalhost:3000/api. That string contains localhost:3000/api as a substring, so the router matches the rule and proxies the request to alt-backend, even though the real host is not localhost:3000 at all. The attacker never had to match the configured host. They only had to end their host string with it.

‍

Severity and exploit conditions

This CVE has two authoritative scores, and they diverge, so cross-reference carefully.

The gap comes from how each version models impact. NVD's v3.1 vector treats the routing bypass as a scope change (S:C) with high integrity impact (I:H), reflecting that a request crossing into an unintended backend can reach a security authority it should never touch. The CNA's v4 vector rates the vulnerable-system integrity impact as low (VI:L) with no scope escalation modeled. HeroDevs classifies this as Medium, in line with the CNA score, while noting NVD's High rating for readers whose risk model weights the backend-crossing scenario more heavily.

Here is the CVSS v3.1 breakdown (the higher of the two, so the conservative view):

Exploit prerequisites are narrow but not exotic. The application must use the router proxy-table with at least one host+path rule. Path-only and host-only rules are not the vulnerable configuration. Where a host+path rule exists, though, the attack is a single ordinary HTTP request with a chosen Host header, no auth, no special tooling.

‍

Exploitation status

There is no evidence of active exploitation in the wild as of publication, and CVE-2026-55602 is not in the CISA Known Exploited Vulnerabilities catalog. CISA's SSVC assessment does tag the vulnerability as proof-of-concept maturity and marks it automatable, meaning a working demonstration path is understood and the attack could be scripted at scale against exposed targets.

The advisory itself documents the crafted-Host-header technique in enough detail to reproduce the routing bypass, so treat the exploitation bar as low for anyone running the vulnerable router configuration on an internet-facing proxy. We do not publish weaponized payloads. The point for defenders is straightforward: if you run a host+path proxy-table on an affected version, assume this is trivially triggerable and prioritize accordingly.

‍

What an attacker can do

The impact depends entirely on what sits behind the backends in your proxy table, but the shape of the attack is consistent:

• Reach an unintended backend. The core primitive. A request meant to be gated to one backend by host is delivered to a different one because the attacker's Host header superstring-matched the wrong rule.
• Bypass host-based access control. If your proxy-table is doing security-relevant routing (for example, sending only trusted-host traffic to an internal admin backend), an attacker can craft a Host header that ends in the trusted value and slip requests through to that backend.
• Set up SSRF-style internal access. When one of the routed backends is an internal service not meant to be reachable from the public host, the bypass becomes a path to it. The attacker controls which rule fires by controlling the tail of their Host string.
• Undermine multi-tenant separation. Any design that relies on host+path routing to keep tenants or environments apart is only as strong as the exact-match assumption this bug breaks.

The one thing this is not: it is not a bug you can trigger without the router proxy-table in play. Single-target proxies and path-only routing are out of scope.

‍

Who is affected?

The 0.16.0 through 1.x range is the EOL exposure. Those lines receive no upstream patch. If you are on 0.19.x because webpack-dev-server 3.x pins it, upgrading the package in isolation is not possible without moving your build tooling. That is the gap HeroDevs Web Essentials closes: NES for http-proxy-middleware 0.19.4 remediates CVE-2026-55602 on the 0.19.x line as a drop-in replacement, so you can stay on your current toolchain and still be patched.

‍

Mitigation guidance

The defense-in-depth step is worth doing regardless. The root cause is that host+path matching was never the exact comparison the docs implied, so any control you build on top of it should validate the full host itself rather than trusting the router to do it.

‍

Related CVEs

http-proxy-middleware and its sibling packages under HeroDevs Web Essentials have a history of transitively inherited exposure worth tracking:

• CVE-2024-21536: a High-severity Denial of Service in http-proxy-middleware (unhandled promise rejection), remediated in the NES 0.19.3 release on the same 0.19.x line.
• The HeroDevs vulnerability directory tracks the ip and webpack-dev-middleware packages that ship alongside http-proxy-middleware in the same legacy toolchains.

‍

Taking action

CVE-2026-55602 is the kind of vulnerability that hides in plain sight. The vulnerable code is in a package almost nobody installs on purpose, on a version line you probably cannot see without reading your lockfile, pinned by a build tool you froze years ago. If you run a host+path router proxy-table on an affected version, a single crafted Host header can route requests to a backend that should never see them, with no authentication.

If you are on a maintained line, upgrade to 2.0.10, 3.0.6, or 4.1.0. That is the right fix and you should take it.

If you are stuck on 0.19.x because webpack-dev-server 3.x or an Angular v9-era toolchain pins it there, the upstream fix does not reach you, and ripping out the build tooling to escape a transitive dependency is rarely a project anyone wants to start. HeroDevs Web Essentials maintains a secure 0.19.x line for exactly this situation: NES for http-proxy-middleware 0.19.4 remediates CVE-2026-55602 as a drop-in replacement, no toolchain migration required. It sits alongside NES coverage for the ip and webpack-dev-middleware packages that travel with it, and there is an Angular v9 integration guide for the most common case.