http-proxy-middleware is a popular npm package for proxying HTTP requests in Node.js, and if you depend on it you should be on version 2.0.9 or 3.0.5 and above, because earlier releases carry two published CVEs. The npm http-proxy-middleware library ships in a huge share of Node development setups and Angular/webpack dev servers, which is exactly why its vulnerabilities are worth understanding rather than ignoring.
This is not a "rip it out" post. The package is actively maintained and the known issues have fixes. It is a "know what you are running and patch it" post.
What the Package Does
http-proxy-middleware wraps the older http-proxy library into Express-style middleware. You mount it on a path and it forwards matching requests to a target server, optionally rewriting paths, headers, and bodies. It is the standard way to proxy /api calls to a backend during local development and, in some setups, in production gateways.
const { createProxyMiddleware } = require('http-proxy-middleware');
app.use('/api', createProxyMiddleware({
target: 'http://internal-service:8080',
changeOrigin: true,
pathRewrite: { '^/api': '' },
}));
That convenience is why it is everywhere, and being everywhere is why its CVEs matter.
CVE-2024-21536: Denial of Service
The more serious of the two is CVE-2024-21536, rated high severity with a CVSS score of 7.5. Versions before 2.0.7, and versions from 3.0.0 up to but not including 3.0.3, are vulnerable to a denial-of-service condition. The root cause is an unhandled promise rejection thrown by the underlying micromatch dependency when certain request paths are processed. An attacker can send requests to specific paths that crash the Node.js process, taking the server down.
The fix is straightforward: upgrade to 2.0.7 or 3.0.3 and above. Because a DoS on a proxy can take out everything behind it, this one deserves prompt attention if you are running an affected version in any internet-facing role.
CVE-2025-32997: Request Integrity
The second advisory, CVE-2025-32997, is moderate severity with a CVSS score around 4.0. In versions before 2.0.9, and 3.x before 3.0.5, the fixRequestBody function proceeds even when the body parser has already failed. This improper handling of an exceptional condition can let an attacker manipulate request integrity by pushing malformed or unexpected body content through the proxy to the upstream service.
The fix is to move to 2.0.9 on the 2.x line or 3.0.5 on the 3.x line. Combined with the DoS fix, the safe floors are 2.0.9 and 3.0.5.
Checking What You Actually Have
Do not guess. The version you install directly is often not the version resolved in your tree, because other packages depend on http-proxy-middleware too. Run:
npm ls http-proxy-middleware
npm audit
npm ls shows every place the package resolves in your dependency graph, including transitive pulls from webpack-dev-server and similar tools. npm audit cross-references the advisory database and tells you whether your resolved versions are affected. An SCA tool will catch the same transitive cases in CI so a vulnerable copy cannot slip in through a sub-dependency without failing the build.
Upgrading Safely
The jump from 2.x to 3.x carries breaking changes; the 3.x line rewrote parts of the API and moved to a different internal structure. If you only need the security fixes and want to minimize churn, staying on the 2.x line and moving to 2.0.9 is the low-risk path. If you are already on 3.x, go to 3.0.5.
After upgrading, exercise the proxy paths in your test suite, because pathRewrite and body-handling behavior are the areas most sensitive to version changes. A quick smoke test against your /api routes catches regressions before they reach staging.
Configuring It Defensively
Beyond patching, a few configuration habits reduce risk:
- Scope the proxy tightly. Mount it on the narrowest path prefix that works, so it never becomes an open relay to arbitrary internal hosts.
- Set
changeOrigindeliberately and understand where the forwardedHostheader lands. - Validate and size-limit request bodies upstream of the proxy so malformed content is rejected before
fixRequestBodyever sees it. - Never expose a development proxy configuration in production; dev-server proxies often trust far more than a hardened gateway should.
Should You Keep Using It?
Yes, for most teams. The package is maintained, the CVEs have fixes, and the alternatives (rolling your own proxy over http/node-fetch, or using a dedicated gateway like nginx or Envoy for production traffic) carry their own trade-offs. The reasonable posture is: keep it, pin to a patched version, scan continuously, and reserve heavier gateways for production edge traffic rather than in-process app proxying.
FAQ
Which http-proxy-middleware versions are safe?
Use 2.0.9 or later on the 2.x line, or 3.0.5 or later on the 3.x line. Those floors include the fixes for both CVE-2024-21536 (denial of service) and CVE-2025-32997 (request integrity).
How serious is CVE-2024-21536?
It is high severity, CVSS 7.5. An attacker can crash the Node.js process by sending requests to certain paths, causing a denial of service. Because it affects a proxy, the outage can cascade to everything behind it, so patching is a priority.
How do I check which version I am running?
Run npm ls http-proxy-middleware to see every resolved instance in your dependency tree, including transitive ones, and npm audit to cross-reference the advisory database. Continuous SCA scanning in CI catches transitive copies automatically.
Is upgrading from 2.x to 3.x risky?
There are breaking API changes between the major versions. If you only need the security fixes, moving to 2.0.9 on the 2.x line is the lowest-risk option. Test your proxy paths after any upgrade because path rewriting and body handling are the most version-sensitive behaviors.