Blakeembrey

multiparty is a Node.js library used for parsing multipart/form-data request bodies. The parser fails to limit the memory used when accumulating headers for a single multipart part. An unauthenticated attacker can exploit this by sending a request containing an excessive volume of header bytes, forcing the parser to buffer the data and exhaust process memory, resulting in a denial of service that crashes the server.

The library fails to properly validate the `domain` and `path` options, checking them against a permissive RFC 7230 field-content matcher that allows semicolons. Because these values are written into the Set-Cookie header unescaped, an application passing untrusted or request-derived data into these options allows for Set-Cookie attribute injection. This can enable an attacker to override attributes such as `SameSite`, `Secure`, `HttpOnly`, or `Domain` on issued cookies.

An authentication and authorization bypass exists due to inconsistent URL decoding between the Fastify router and the static file handler. The router treats percent-encoded path separators (`%2F`) as literal characters, while the static handler decodes them before filesystem resolution. This mismatch allows attackers to circumvent route-based middleware or guards intended to protect specific paths. For example, a request to `/admin%2Fsecret.html` may not match a guard for `/admin/*` but will still be resolved and served as `/admin/secret.html` by the static handler.

The software is susceptible to a Regular Expression Denial of Service (ReDoS) condition when handling multiple wildcard characters combined with at least one parameter. This issue arises because the generated regular expression can lead to excessive backtracking when the second wildcard is not at the end of the path. Unsafe examples include '/*foo-*bar-:baz', '/*a-:b-*c-:d', and '/x/*a-:b/*c/y'. Safe examples include '/*foo-:bar' and '/*foo-:bar-*baz'. ReDoS is a type of attack where a carefully crafted input causes the regular expression engine to take an extremely long time to process, potentially leading to a denial of service.

A flawed regular expression is created when multiple sequential optional groups (using curly brace syntax) are present, such as `{a}{b}{c}:z`. The resulting regular expression expands exponentially with the number of groups, potentially leading to a denial of service. Avoid passing user-controlled input as route patterns.

The issue concerns a performance vulnerability in path-to-regexp, where certain inputs can generate regular expressions vulnerable to backtracking, leading to poor performance. This vulnerability exists due to an incomplete fix.

The cookie name could be used to set other fields of the cookie, resulting in an unexpected cookie value. A similar escape can be used for `path` and `domain`, which could be abused to alter other fields of the cookie. For example, `serialize("userName=<script>alert('XSS3')</script>; Max-Age=2592000; a", value)` would result in `"userName=<script>alert('XSS3')</script>; Max-Age=2592000; a=test"`, setting `userName` cookie to `<script>` and ignoring `value`.

A flawed regular expression is generated when three or more parameters are present within a single segment, separated by characters other than a period (`.`). For example, `/:a-:b-:c` or `/:a-:b-:c-:d`. The backtrack protection introduced in `path-to-regexp@0.1.12` only addresses ambiguity for two parameters. With three or more parameters, the generated lookahead does not prevent single separator characters from causing capture groups to overlap, leading to catastrophic backtracking. Custom regular expression patterns defined in route definitions, such as `/:a-:b([^-/]+)-:c([^-/]+)`, are not affected as they override the default capture group.

The issue arises when path-to-regexp generates a regular expression that can cause poor performance, leading to a Denial of Service (DoS). This occurs when there are two parameters within a single segment, separated by something that is not a period (.). For example, `/:a-:b` can produce a regular expression that can be exploited. The estimated impact is significant, with performance being over 1000x worse than safe regex in local benchmarks. In a realistic environment, this can result in average latency of ~600ms vs 1ms.