Package Instance

Undici has Unhandled Exception in WebSocket Client Due to Invalid server_max_window_bits Validation
### Impact

The undici WebSocket client is vulnerable to a denial-of-service attack due to improper validation of the `server_max_window_bits` parameter in the permessage-deflate extension. When a WebSocket client connects to a server, it automatically advertises support for permessage-deflate compression. A malicious server can respond with an out-of-range `server_max_window_bits` value (outside zlib's valid range of 8-15). When the server subsequently sends a compressed frame, the client attempts to create a zlib InflateRaw instance with the invalid windowBits value, causing a synchronous RangeError exception that is not caught, resulting in immediate process termination.

The vulnerability exists because:

1. The `isValidClientWindowBits()` function only validates that the value contains ASCII digits, not that it falls within the valid range 8-15
2. The `createInflateRaw()` call is not wrapped in a try-catch block
3. The resulting exception propagates up through the call stack and crashes the Node.js process

### Patches
_Has the problem been patched? What versions should users upgrade to?_

### Workarounds
_Is there a way for users to fix or remediate the vulnerability without upgrading?_

minimatch has a ReDoS via repeated wildcards with non-matching literal in pattern
### Summary
`minimatch` is vulnerable to Regular Expression Denial of Service (ReDoS) when a glob pattern contains many consecutive `*` wildcards followed by a literal character that doesn't appear in the test string. Each `*` compiles to a separate `[^/]*?` regex group, and when the match fails, V8's regex engine backtracks exponentially across all possible splits.

The time complexity is O(4^N) where N is the number of `*` characters. With N=15, a single `minimatch()` call takes ~2 seconds. With N=34, it hangs effectively forever.


### Details
_Give all details on the vulnerability. Pointing to the incriminated source code is very helpful for the maintainer._

### PoC
When minimatch compiles a glob pattern, each `*` becomes `[^/]*?` in the generated regex. For a pattern like `***************X***`:

```
/^(?!\.)[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?[^/]*?X[^/]*?[^/]*?[^/]*?$/
```

When the test string doesn't contain `X`, the regex engine must try every possible way to distribute the characters across all the `[^/]*?` groups before concluding no match exists. With N groups and M characters, this is O(C(N+M, N)) — exponential.
### Impact
Any application that passes user-controlled strings to `minimatch()` as the pattern argument is vulnerable to DoS. This includes:
- File search/filter UIs that accept glob patterns
- `.gitignore`-style filtering with user-defined rules
- Build tools that accept glob configuration
- Any API that exposes glob matching to untrusted input

----

Thanks to @ljharb for back-porting the fix to legacy versions of minimatch.

Undici has an HTTP Request/Response Smuggling issue
### Impact

Undici allows duplicate HTTP `Content-Length` headers when they are provided in an array with case-variant names (e.g., `Content-Length` and `content-length`). This produces malformed HTTP/1.1 requests with multiple conflicting `Content-Length` values on the wire.

**Who is impacted:**
  - Applications using `undici.request()`, `undici.Client`, or similar low-level APIs with headers passed as flat arrays
  - Applications that accept user-controlled header names without case-normalization

**Potential consequences:**
  - **Denial of Service**: Strict HTTP parsers (proxies, servers) will reject requests with duplicate `Content-Length` headers (400 Bad Request)
  - **HTTP Request Smuggling**: In deployments where an intermediary and backend interpret duplicate headers inconsistently (e.g., one uses the first value, the other uses the last), this can enable request smuggling attacks leading to ACL bypass, cache poisoning, or credential hijacking

### Patches

 Patched in the undici version v7.24.0 and v6.24.0. Users should upgrade to this version or later.

### Workarounds

  If upgrading is not immediately possible:

  1. **Validate header names**: Ensure no duplicate `Content-Length` headers (case-insensitive) are present before passing headers to undici
  2. **Use object format**: Pass headers as a plain object (`{ 'content-length': '123' }`) rather than an array, which naturally deduplicates by key
  3. **Sanitize user input**: If headers originate from user input, normalize header names to lowercase and reject duplicates

Undici has CRLF Injection in undici via `upgrade` option
### Impact

When an application passes user-controlled input to the `upgrade` option of `client.request()`, an attacker can inject CRLF sequences (`\r\n`) to:

1. Inject arbitrary HTTP headers
2. Terminate the HTTP request prematurely and smuggle raw data to non-HTTP services (Redis, Memcached, Elasticsearch)

The vulnerability exists because undici writes the `upgrade` value directly to the socket without validating for invalid header characters:

```javascript
// lib/dispatcher/client-h1.js:1121
if (upgrade) {
  header += `connection: upgrade\r\nupgrade: ${upgrade}\r\n`
}
```

### Patches

 Patched in the undici version v7.24.0 and v6.24.0. Users should upgrade to this version or later.

### Workarounds

Sanitize the `upgrade` option string before passing to undici:

```javascript
function sanitizeUpgrade(value) {
  if (/[\r\n]/.test(value)) {
    throw new Error('Invalid upgrade value')
  }
  return value
}

client.request({
  upgrade: sanitizeUpgrade(userInput)
})
```