multiparty vulnerable to Denial of Service via Uncaught Exception in filename* parameter parsing
[email protected] and lower versions are vulnerable to denial of service via uncaught exception. By sending a multipart/form-data request with a Content-Disposition header whose filename* parameter contains a malformed percent-encoding, the parser invokes decodeURI on the value without try/catch. The resulting URIError propagates as an uncaught exception and crashes the process. Impact: any service accepting multipart uploads via multiparty is affected. Workarounds: none. Upgrade to [email protected] or higher.
multiparty vulnerable to Denial of Service via Prototype Pollution leading to Uncaught Exception
[email protected] and lower versions are vulnerable to denial of service via uncaught exception. By sending a multipart/form-data request with a field name that collides with an inherited Object.prototype property such as __proto__, constructor, or toString, the parser invokes .push() on the inherited prototype value rather than an array, throwing a TypeError that propagates as an uncaught exception and crashes the process. Impact: any service accepting multipart uploads via multiparty is affected. Workarounds: none. Upgrade to [email protected] or higher.
multiparty vulnerable to ReDoS via filename parsing
[email protected] and lower versions are vulnerable to denial of service via regular expression backtracking in the Content-Disposition filename parameter parser. A crafted multipart upload with a long header value can cause regex matching to take seconds, blocking the event loop. Impact: any service accepting multipart uploads via multiparty is affected. Workarounds: limiting upload sizes at the proxy or gateway layer reduces but does not eliminate the attack surface, since a small header of around 8 KB is sufficient to trigger the vulnerable backtracking. Upgrade to [email protected] or higher.