Impact

multiparty@4.2.3 and lower versions are vulnerable to denial of service via uncaught exception. By sending a multipart/form-data request with a Content-Disposition: filename=utf-8'' header containing a malformed percent-encoding (e.g., %FF, %GG), the parser invokes decodeURI on the value without try/catch. The resulting URIError propagates as an uncaught exception and crashes the process. Any service accepting multipart uploads via multiparty is affected.

Patches

Users should upgrade to multiparty@4.3.0 or higher.

Workarounds

None.

Impact

multiparty@4.2.3 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 (e.g., proto, constructor, 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. Any service accepting multipart uploads via multiparty is affected.

Patches

Users should upgrade to multiparty@4.3.0 or higher.

Workarounds

None.

Impact

multiparty@4.2.3 and lower versions are vulnerable to denial of service via regular expression backtracking in the Content-Disposition filename parameter parser. A multipart upload with a long header value containing !filename="1 repeated can cause regex matching to take seconds, blocking the event loop. Any service accepting multipart uploads via multiparty is affected.

Patches

Users should upgrade to multiparty@4.3.0 or higher.

Workarounds

None. Limiting upload sizes at the proxy/gateway layer reduces but does not eliminate the attack surface, since a small ~8 KB header is sufficient to trigger the vulnerable backtracking.

Resources

- OWASP: Regular expression Denial of Service (ReDoS)

Impact

When using multiple wildcards, combined with at least one parameter, a regular expression can be generated that is vulnerable to ReDoS. This backtracking vulnerability requires the second wildcard to be somewhere other than the end of the path.

Unsafe examples:

/foo-bar-:baz /a-:b-c-:d /x/a-:b/c/y

Safe examples:

/foo-:bar /foo-:bar-baz

Patches

Upgrade to version 8.4.0.

Workarounds

If developers are using multiple wildcard parameters, they can check the regex output with a tool such as https://makenowjust-labs.github.io/recheck/playground/ to confirm whether a path is vulnerable.

Impact

A bad regular expression is generated any time you have multiple sequential optional groups (curly brace syntax), such as {a}{b}{c}:z. The generated regex grows exponentially with the number of groups, causing denial of service.

Patches

Fixed in version 8.4.0.

Workarounds

Limit the number of sequential optional groups in route patterns. Avoid passing user-controlled input as route patterns.

Impact

A bad regular expression is generated any time you have three or more parameters within a single segment, separated by something that is not a period (.). For example, /:a-:b-:c or /:a-:b-:c-:d. The backtrack protection added in path-to-regexp@0.1.12 only prevents ambiguity for two parameters. With three or more, the generated lookahead does not block single separator characters, so capture groups overlap and cause catastrophic backtracking.

Patches

Upgrade to path-to-regexp@0.1.13

Custom regex patterns in route definitions (e.g., /:a-:b([^-/]+)-:c([^-/]+)) are not affected because they override the default capture group.

Workarounds

All versions can be patched by providing a custom regular expression for parameters after the first in a single segment. As long as the custom regular expression does not match the text before the parameter, you will be safe. For example, change /:a-:b-:c to /:a-:b([^-/]+)-:c([^-/]+).

If paths cannot be rewritten and versions cannot be upgraded, another alternative is to limit the URL length.

References

- GHSA-9wv6-86v2-598j - Detailed blog post: ReDoS the web