CVE-2026-8159

What it actually does

The vulnerability is a denial-of-service flaw in pillarjs multiparty versions 4.2.3 and earlier. The multipart parser uses a vulnerable regular expression when processing the Content-Disposition filename parameter. A specially crafted multipart/form-data upload with a long filename header can trigger excessive regex backtracking, causing Node.js to spend seconds processing a single request. Because Node.js applications commonly rely on a single event loop per worker, this can block other requests handled by that worker and degrade or exhaust service availability. The issue is remotely reachable, requires no authentication, and affects services that accept multipart uploads through multiparty.

Why it matters to the business

An unauthenticated remote attacker can degrade or interrupt web applications that accept file uploads, potentially causing failed uploads, slow API responses, application timeouts, customer-facing outages, and increased infrastructure load. The EPSS score is currently low and this is not listed in CISA KEV, but the issue is easy to trigger over the network and has been public for about 90 days, so internet-facing upload endpoints should still be prioritized for remediation.

How an attack unfolds

An attacker identifies an application endpoint that accepts multipart/form-data uploads and is backed by multiparty 4.2.3 or earlier. The attacker sends a POST request containing a multipart body with a crafted Content-Disposition header, specifically manipulating the filename parameter with a long value of roughly several kilobytes. When the vulnerable parser evaluates the header, the regular expression enters costly backtracking behavior. Repeating these requests can keep one or more Node.js event-loop workers busy, causing legitimate requests to queue, timeout, or fail. The attack does not require valid credentials, user interaction, or a large request body, so proxy upload-size limits reduce but do not fully remove risk.

How to fix it

Upgrade pillarjs multiparty to version 4.3.0 or later wherever it is used, including direct and transitive dependencies. Regenerate lockfiles and redeploy affected services after confirming the resolved version is in use. If immediate upgrade is not possible, apply compensating controls: restrict access to upload endpoints where feasible, enforce strict request header-size limits at the reverse proxy or gateway, rate-limit multipart upload requests per IP/session/API key, cap request concurrency, and configure application-level timeouts. Upload body-size limits alone are insufficient because a relatively small header of about 8 KB may trigger the condition.

How to confirm the fix worked

Confirm that dependency manifests and runtime deployments no longer include multiparty 4.2.3 or earlier. Use package manager inspection such as npm ls multiparty, yarn why multiparty, pnpm why multiparty, and lockfile review to verify version 4.3.0 or later. Validate container images and deployed artifacts rather than only source repositories. Exercise upload endpoints with normal multipart uploads after upgrading to confirm functionality. Review gateway/proxy configuration to ensure header-size limits, request timeouts, and rate limits are active for upload routes. If safe testing is authorized, perform controlled performance testing against non-production upload endpoints to verify malformed long filename headers no longer cause event-loop stalls or request-time amplification.

Typical attack path

1. Discover an application endpoint that accepts multipart/form-data uploads, such as file upload, avatar upload, document import, or attachment APIs.
2. Send a crafted HTTP POST request with multipart/form-data content and a long Content-Disposition filename parameter.
3. Trigger catastrophic or excessive regex backtracking inside the multiparty filename parser.
4. Repeat requests concurrently or serially to block Node.js event-loop workers.
5. Cause degraded application responsiveness, request timeouts, failed uploads, or full denial of service depending on worker capacity and upstream timeout behavior.

How to detect it

To assess possible exploitation, review HTTP access logs, reverse-proxy logs, WAF logs, application logs, APM traces, and Node.js runtime metrics for upload endpoints. Focus on POST requests with Content-Type multipart/form-data and unusually long Content-Disposition filename parameters, especially requests with small bodies but large headers, repeated requests from the same source, high request duration, 408/499/500/502/503/504 responses, and upstream timeout messages. Correlate suspicious requests with increases in Node.js event-loop lag, CPU saturation in Node.js workers, request queueing, failed upload operations, and application restarts. Because no public malware artifact or stable payload string is inherent to this vulnerability, detection should emphasize behavioral patterns: long multipart headers, abnormal filename lengths, request-time amplification, and clustered timeout events around upload routes.

• multipart/form-data
• Content-Disposition: form-data
• filename=
• upstream timed out
• client timed out
• request timed out
• HTTP 504
• HTTP 503
• event loop delay
• eventLoopDelay
• Event loop blocked
• multiparty@4.2.3
• multiparty@4.2.2
• multiparty@4.2.1
• multiparty@4.2.0
• node_modules/multiparty

What your security team should do

• Inventory all internet-facing and internal services that accept multipart/form-data uploads and use Node.js dependencies.
• Identify all direct and transitive uses of pillarjs multiparty and prioritize upgrade to multiparty 4.3.0 or later.
• Patch internet-facing upload services first, especially unauthenticated upload endpoints.
• Deploy or tune reverse-proxy and gateway controls for request header size, upload route rate limiting, request timeouts, and concurrency limits.
• Add monitoring for spikes in multipart POST requests, long Content-Disposition headers, elevated Node.js event-loop delay, 4xx/5xx bursts, and upstream timeout errors.
• Search recent logs for suspicious multipart requests with unusually long filename parameters to assess possible prior exploitation.
• Ensure dependency scanning policies flag multiparty versions 4.2.3 and earlier as vulnerable in repositories, CI pipelines, container images, and deployed artifacts.