CVE-2026-8161

What it actually does

CVE-2026-8161 is a remotely triggerable denial-of-service flaw in pillarjs multiparty versions 4.2.3 and earlier. When parsing multipart/form-data, multiparty stores parsed fields in a plain JavaScript object. If an attacker supplies a multipart field name that collides with an inherited Object.prototype property, such as __proto__, constructor, or toString, the parser may treat the inherited value as though it were the expected field array and call .push() on it. Because the inherited value is not an array, Node.js throws a TypeError. If the application does not catch that exception, the process can terminate, making the upload-handling service unavailable.

Why it matters to the business

Any internet-facing or internal service that accepts file uploads or multipart form submissions through vulnerable multiparty versions can be crashed by a single unauthenticated request. The main operational risk is service downtime, failed uploads or form submissions, health-check failures, container or process restart loops, and degraded availability for dependent applications. The CVSS score is high for availability impact, but EPSS is currently low and the issue is not listed in CISA KEV, so remediation should be prioritized for exposed upload endpoints and business-critical services rather than treated as evidence of active widespread exploitation.

How an attack unfolds

An attacker identifies an endpoint that accepts multipart/form-data, such as a file upload, profile form, support attachment, import feature, or API endpoint using multiparty. The attacker sends a crafted multipart request containing a field whose name matches an inherited JavaScript Object.prototype property, for example __proto__, constructor, or toString. During parsing, vulnerable multiparty versions 4.2.3 and earlier attempt to append the field value using .push() on what should be an array. Because the property resolves to an inherited prototype value rather than an initialized array, a TypeError is thrown. In typical Node.js applications where this exception is not safely handled around the parser, the uncaught exception terminates the process. An attacker can repeat the request to keep the service down or force repeated restarts under a process manager or container orchestrator.

How to fix it

Upgrade pillarjs multiparty to version 4.3.0 or later wherever it is used. There are no reliable application-level workarounds identified by the advisory, so dependency remediation is the primary fix. Rebuild and redeploy affected services after upgrading, and ensure lockfiles and container images are refreshed so the vulnerable transitive or direct dependency is removed. As defense in depth, validate and reject unexpected multipart field names at the application or edge layer, limit request size and upload rates, and ensure Node.js services are supervised so they restart cleanly; however, these controls should not be considered substitutes for upgrading.

How to confirm the fix worked

Confirm package inventory shows multiparty version 4.3.0 or later in package manifests, lockfiles, deployed artifacts, and container images. Use package-manager checks such as npm ls multiparty, npm audit, software composition analysis, or container image scanning to verify no deployed service still includes multiparty 4.2.3 or earlier. Exercise relevant upload and multipart form endpoints in a non-production environment with prototype-colliding field names such as __proto__, constructor, and toString and confirm the service returns a controlled error or handles the request without crashing. Validate process uptime, health checks, and application logs during testing to ensure no uncaught TypeError occurs.

Typical attack path

1. Discover an application endpoint that accepts multipart/form-data requests.
2. Confirm the endpoint is backed by a Node.js service using vulnerable multiparty parsing behavior.
3. Send a multipart/form-data request containing a field name that collides with Object.prototype, such as __proto__, constructor, or toString.
4. Trigger a TypeError when multiparty attempts to call .push() on the inherited prototype value.
5. Cause the Node.js process to crash if the exception is uncaught.
6. Repeat the request to sustain denial of service or cause restart loops.

How to detect it

To determine whether this was already exploited, review application access logs, reverse proxy logs, WAF logs, API gateway logs, Node.js application logs, process manager logs, and container/orchestrator events for the same time windows. Look for multipart/form-data POST requests to upload or form endpoints containing field names such as __proto__, constructor, or toString, especially if followed by HTTP 500 responses, connection resets, service restarts, container restarts, or health-check failures. In Node.js logs, look for uncaught exceptions with TypeError messages involving .push not being a function and stack traces referencing node_modules/multiparty. Correlate suspicious requests with process exits, PM2/systemd/Kubernetes restart events, increased restart counts, and bursts of repeated requests from the same source IP or user agent. Because this vulnerability causes denial of service rather than code execution, expected artifacts are crash logs, request traces, and availability events rather than persistence files or new processes.

• multipart/form-data
• name="__proto__"
• name="constructor"
• name="toString"
• TypeError: fields[name].push is not a function
• TypeError: .push is not a function
• Uncaught TypeError
• uncaughtException
• node_modules/multiparty
• node_modules/multiparty/index.js
• POST /upload
• POST /uploads
• POST /api/upload
• POST /files
• POST /import
• CrashLoopBackOff
• OOMKilled=false
• Error: write EPIPE

What your security team should do

• Identify all applications, APIs, and container images that include pillarjs multiparty, especially internet-facing upload or form-submission services.
• Upgrade multiparty to 4.3.0 or later and redeploy affected services; verify lockfiles and runtime images no longer contain versions 4.2.3 or earlier.
• Prioritize remediation for unauthenticated upload endpoints, high-availability services, and systems where repeated process crashes would affect customers or operations.
• Add temporary edge or application-layer filtering for multipart field names such as __proto__, constructor, and toString if immediate upgrade is not possible, understanding this is only a compensating control.
• Review Node.js process supervision, crash handling, and rate limiting to reduce the operational impact of repeated malformed upload requests.
• Search historical logs for suspicious multipart requests and Node.js crash signatures consistent with this issue.
• Monitor for repeated 5xx responses, process restarts, container restarts, or uncaught TypeError events around multipart upload endpoints.