Blakeembrey

multiparty is a Node.js library for parsing multipart/form-data request bodies. In versions from 2.1.0 up to but not including 4.3.1, the parser does not bound the amount of memory used while accumulating the headers of a single multipart part. An unauthenticated attacker can send a single request whose part carries a very large volume of header bytes, forcing the parser to buffer all of them and exhausting the process memory, which crashes the server. This is a denial of service with no confidentiality or integrity impact. The issue is fixed in multiparty 4.3.1, which caps the size of the accumulated part headers. Users should upgrade to multiparty 4.3.1 or later.

cookies is a Node.js library for reading and writing HTTP cookies, used by Koa via ctx.cookies. In versions before 0.9.2 the library validates the cookie name and value against character sets that reject the semicolon separator, but the domain and path options are checked only against a permissive RFC 7230 field-content matcher that allows semicolons, and both are written into the Set-Cookie header unescaped. An application that passes untrusted or request-derived data into the domain or path option can therefore inject additional cookie attributes, overriding SameSite, Secure, HttpOnly, or Domain on the cookies the application issues. This is a Set-Cookie attribute injection issue (CWE-74). The issue is fixed in cookies 0.9.2, which validates domain and path against RFC 6265 character sets. As a workaround, keep domain and path application-set rather than derived from untrusted input.

**Name of the Vulnerable Software and Affected Versions** @fastify/static versions 8.0.0 through 9.1.0 **Description** 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. **Recommendations** Upgrade @fastify/static to version 9.1.1.

**Name of the Vulnerable Software and Affected Versions** path-to-regexp versions prior to 8.4.0 **Description** 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. **Recommendations** Versions prior to 8.4.0 should be upgraded to version 8.4.0. If using multiple wildcard parameters, check the regex output with a tool to confirm whether a path is vulnerable.

**Name of the Vulnerable Software and Affected Versions** path-to-regexp versions prior to 8.4.0 **Description** 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. **Recommendations** Versions prior to 8.4.0 should be updated to version 8.4.0 or later. Limit the number of sequential optional groups in route patterns.

**Name of the Vulnerable Software and Affected Versions** path-to-regexp versions 0.1.x through 0.1.11 **Description** 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. **Recommendations** Upgrade to version 0.1.12. As a temporary workaround, consider avoiding the use of two parameters within a single path segment when the separator is not `.` (e.g., no `/:a-:b`). Alternatively, define the regex used for both parameters and ensure they do not overlap to allow backtracking.

**Name of the Vulnerable Software and Affected Versions** cookie versions prior to 0.7.0 **Description** 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`. **Recommendations** Upgrade to 0.7.0, which updates the validation for `name`, `path`, and `domain`. As a temporary workaround, avoid passing untrusted or arbitrary values for these fields, ensure they are set by the application instead of user input.

**Name of the Vulnerable Software and Affected Versions** path-to-regexp versions prior to 0.1.13 **Description** 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. **Recommendations** Upgrade to path-to-regexp@0.1.13. As a workaround, provide a custom regular expression for parameters after the first in a single segment, ensuring it does not match the text preceding the parameter. For example, change `/:a-:b-:c` to `/:a-:b([^-/]+)-:c([^-/]+)`. If paths cannot be rewritten and versions cannot be upgraded, limit the URL length.

**Name of the Vulnerable Software and Affected Versions** path-to-regexp versions prior to 0.1.10 path-to-regexp versions prior to 8.0.0 **Description** 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. **Recommendations** For users of 0.1, upgrade to 0.1.10. For all other users, upgrade to 8.0.0. As a temporary workaround, consider providing a custom regular expression for parameters after the first in a single segment, ensuring it does not match the text before the parameter. Alternatively, limit the URL length to improve performance, for example, by halving the attack string, which can improve performance by 4x faster.