CVE-2024-21536

What it actually does

The vulnerable versions of http-proxy-middleware can throw an unhandled Promise rejection while evaluating certain request paths through micromatch-based matching logic. When the affected proxy middleware processes a crafted path that triggers this failure, the exception is not safely contained by the application. In Node.js runtimes or process configurations where unhandled rejections terminate the process, this can crash the Node.js service, causing a denial of service. The issue affects http-proxy-middleware versions before 2.0.7 and versions 3.0.0 through before 3.0.3, as well as downstream software that embeds or vendors vulnerable versions, including kubernetes-sigs/image-builder before 0.1.38.

Why it matters to the business

Successful exploitation can make web applications, developer portals, API gateways, reverse-proxy services, or build/deployment tooling that rely on the vulnerable package unavailable until the process is restarted. The direct consequence is service interruption rather than data theft or code execution, but repeated requests can cause recurring outages, failed health checks, degraded user experience, and operational alert fatigue. This vulnerability is not listed in CISA KEV, is not known to be used in ransomware campaigns, and currently has low EPSS likelihood, but it has been public for a long time and the affected package is commonly embedded as a dependency in JavaScript applications, so exposure may exist indirectly through transitive dependencies.

How an attack unfolds

An attacker first identifies a reachable application route that uses http-proxy-middleware to proxy or filter incoming requests. The attacker then sends HTTP requests containing path values that exercise the vulnerable micromatch matching behavior. In affected versions, the path evaluation can raise an unhandled Promise rejection. If the application or Node.js runtime treats that rejection as fatal, the Node.js process exits or becomes unavailable. The attacker can repeat the request after the service restarts to create a sustained denial-of-service condition. No authentication is required if the vulnerable proxy route is publicly reachable; if the route is internal, exploitation requires network access to that route.

How to fix it

Upgrade affected dependencies. For http-proxy-middleware 2.x, upgrade to version 2.0.7 or later. For http-proxy-middleware 3.x, upgrade to version 3.0.3 or later. For kubernetes-sigs/image-builder, upgrade to 0.1.38 or later. If pinning from source, use a version that includes commit 1e9233909839962bb3c1980848ad499b4757a71d or a later fixed revision. Regenerate and redeploy lockfiles after upgrading, and verify that transitive dependency resolution does not retain a vulnerable copy. If immediate upgrade is not possible, reduce exposure by restricting access to affected proxy routes, applying rate limits, filtering abnormal path patterns at an upstream proxy or WAF, and ensuring process supervision restarts failed services; however, restart supervision is only an availability mitigation and does not remove the vulnerability.

How to confirm the fix worked

Confirm package versions using dependency tooling such as npm ls http-proxy-middleware, yarn why http-proxy-middleware, pnpm why http-proxy-middleware, software composition analysis, or lockfile review. Validate that no deployed artifact contains http-proxy-middleware versions before 2.0.7 or versions 3.0.0 through before 3.0.3. For downstream image-builder usage, confirm version 0.1.38 or later. After patching, exercise representative proxy routes in a non-production environment with unusual but non-destructive path inputs and confirm the Node.js process does not log micromatch-related unhandled rejections, does not exit, and continues to pass health checks. Also verify container images, serverless bundles, and build artifacts were rebuilt from updated dependencies rather than only updating source manifests.

Typical attack path

1. Discover an application endpoint or service route backed by http-proxy-middleware.
2. Send crafted HTTP requests with path values that reach the middleware's path matching or filtering logic.
3. Trigger a micromatch-related unhandled Promise rejection inside the vulnerable package version.
4. Cause the Node.js process to terminate or the service to become unhealthy, depending on runtime and process-manager behavior.
5. Repeat requests to keep the service unstable or unavailable despite automatic restarts.

How to detect it

To determine whether exploitation may already have occurred, review application logs, Node.js stderr/stdout, process-manager logs, container logs, orchestrator events, reverse-proxy access logs, and availability monitoring. Look for abrupt Node.js exits or container restarts immediately following unusual HTTP requests to proxied routes. Correlate spikes in 500, 502, 503, or 504 responses with log messages mentioning unhandled Promise rejections, micromatch, or http-proxy-middleware. In Kubernetes or containerized environments, review restart counts, liveness/readiness probe failures, OOM-independent exits, and pod events showing repeated application crashes. In systemd, PM2, forever, supervisord, or similar process managers, look for rapid restart loops where the crash stack trace references micromatch or http-proxy-middleware. Network indicators are path-dependent and no universal malicious path string is publicly derivable from the provided data, so detection should focus on crash artifacts and correlation with inbound requests rather than a single payload signature.

• UnhandledPromiseRejection
• UnhandledPromiseRejectionWarning
• ERR_UNHANDLED_REJECTION
• unhandled promise rejection
• micromatch
• http-proxy-middleware
• at micromatch
• node:internal/process/promises
• This error originated either by throwing inside of an async function without a catch block
• Promise rejection was handled asynchronously
• Process exited with code 1
• npm ls http-proxy-middleware

What your security team should do

• Inventory applications, containers, and build tooling that include http-proxy-middleware, including transitive dependencies in package lockfiles.
• Prioritize patching internet-facing proxy routes, API gateways, developer portals, and services where a Node.js process crash would affect production availability.
• Upgrade http-proxy-middleware to 2.0.7 or later on the 2.x branch, or 3.0.3 or later on the 3.x branch; upgrade kubernetes-sigs/image-builder to 0.1.38 or later where applicable.
• Add monitoring for Node.js process exits, container restarts, failed liveness probes, and log entries containing unhandled Promise rejections involving micromatch or http-proxy-middleware.
• Apply temporary access controls, request rate limiting, and upstream request filtering for exposed proxy routes until all affected deployments are patched.
• Review incident data for repeated service restarts or 5xx spikes around proxy endpoints since the vulnerability became public.