CVE-2026-8162

What it actually does

A remote, unauthenticated attacker can cause a denial of service by crashing the application process. The vulnerability exists in the multipart/form-data parser, which fails to handle malformed percent-encoding in the 'filename*' parameter of the Content-Disposition header. This triggers an uncaught 'URIError' exception, which propagates up the stack and terminates the Node.js process.

Why it matters to the business

Any web service using a vulnerable version of the 'multiparty' library for file uploads is susceptible to a complete denial of service. An attacker can repeatedly crash the service, making it unavailable to legitimate users. This can lead to operational disruption, reputational damage, and a poor user experience, especially for services that rely on user-submitted content.

How an attack unfolds

An unauthenticated attacker identifies a web application that accepts multipart/form-data uploads and uses the vulnerable 'multiparty' library. The attacker crafts a malicious HTTP request containing a 'Content-Disposition' header. Within this header, the 'filename*' parameter is set to a string with a malformed percent-encoded sequence (e.g., a '%' not followed by two valid hexadecimal characters). When the server-side 'multiparty' library attempts to parse this header, it calls 'decodeURI' on the malformed string. This function throws a 'URIError' exception. Because the library does not handle this specific error, the exception remains uncaught, causing the entire Node.js application process to crash immediately.

How to fix it

The primary remediation is to upgrade the 'multiparty' package to version 4.3.0 or a later version. No workarounds have been identified. You can perform the upgrade using your package manager, for example, by running 'npm install multiparty@latest' or 'yarn upgrade multiparty --latest' and updating your 'package.json' file accordingly. After upgrading, ensure you redeploy your application.

How to confirm the fix worked

To confirm remediation, check your project's dependency lock file (e.g., 'package-lock.json', 'yarn.lock') to ensure that the resolved version of 'multiparty' is 4.3.0 or higher. You can also run 'npm ls multiparty' or 'yarn why multiparty' in your project's root directory to verify the installed version and ensure no vulnerable versions are present in the dependency tree. For active validation, a test case can be created to send a request with a malformed 'filename*' parameter to a non-production instance of the application to confirm it no longer crashes.

Typical attack path

1. The attacker identifies a target application that accepts file uploads.
2. The attacker crafts a multipart/form-data HTTP POST request.
3. In the request, the attacker includes a part with a 'Content-Disposition' header containing a 'filename*' parameter with a malformed percent-encoded value.
4. The attacker sends the malicious request to the application endpoint.
5. The server-side 'multiparty' library attempts to parse the header, triggering an uncaught 'URIError'.
6. The Node.js process hosting the application crashes, resulting in a denial of service.

How to detect it

To detect potential exploitation, review application logs for evidence of unexpected crashes or restarts. Specifically, search for uncaught 'URIError' exceptions in the standard error output or log files of your Node.js applications. Additionally, analyze web server or API gateway access logs for incoming multipart/form-data requests where the 'Content-Disposition' header contains a 'filename*' parameter with unusual or malformed percent-encoded strings.

• log:URIError: URI malformed
• http_header:Content-Disposition: form-data; name="file"; filename*=%E0%A4%A

What your security team should do

• Immediately identify all Node.js applications using the 'multiparty' library and audit their versions. Prioritize patching for public-facing services.
• Upgrade all instances of 'multiparty' to version 4.3.0 or newer to eliminate the vulnerability.
• As a general resilience measure, ensure critical Node.js services are run with a process manager (like PM2 or systemd) configured to automatically restart them after a crash. This mitigates the immediate impact of this and similar DoS vulnerabilities but does not fix the root cause.