GitLab Advisory Database (GLAD)

[!IMPORTANT] CVE-2026-76844 was assigned and published for this issue by VulnCheck on 2026-08-24 without prior coordination with the webpack maintainers or the OpenJS Foundation, which holds the CVE Numbering Authority scope for webpack projects. Neither the maintainers nor the OpenJS CNA were notified before publication, and no fix was available at that time. This advisory is the coordinated record produced by the webpack maintainers and the OpenJS Foundation CNA.

undici's BalancedPool passes its constructor options through a JSON-based deep clone (JSON.parse(JSON.stringify(…))) before forwarding them to each per-upstream Pool. JSON cannot represent functions, so a caller-supplied connect or tls option containing a checkServerIdentity callback (or a custom connector function) is silently dropped before it reaches the TLS layer. As a result, a TLS peer whose certificate a custom checkServerIdentity was written to reject, but which passes Node's default hostname and …

undici's interceptors.dump() reads and discards response bodies up to a configurable maxSize. When a response declares a Content-Length that exceeds maxSize, the request is aborted cleanly. When a response is sent chunked (no Content-Length) and its body exceeds maxSize, it is not aborted: the interceptor ends the response early once the accumulated size reaches maxSize, and continued delivery from the parser triggers an internal assertion that is caught and turned …

Undici's interceptors.retry() can resume a request after a partial response and append the resumed bytes to an already partially delivered body, while the application still receives the original response's status and headers. When that response carried a Content-Length, the application can receive a longer body. Applications that forward Undici's status, headers, and body downstream without recalculating framing, for example proxy or gateway applications, may emit a response whose body exceeds …

undici's WebSocketStream crashes the client process when a WebSocket connection is closed abruptly without a close handshake. On such an unclean close, the internal socket-close handler calls abort() on the writable stream even when the application holds a writer lock. Per the WHATWG Streams standard, aborting a locked stream returns a promise that rejects with a TypeError, and the handler discards that promise. The unobserved rejection surfaces as an unhandledRejection …

The undici WebSocket client throws an uncaught TypeError during the opening handshake when a server's 101 response includes a Sec-WebSocket-Protocol header that the client never requested. The throw occurs in a queueMicrotask callback with no surrounding try/catch, so it propagates as an uncaught exception and terminates the Node.js process. This is a remote, unauthenticated denial of service against any application that opens a WebSocket to an attacker controlled or compromised …

The interceptors.decompress() interceptor decompresses HTTP response bodies according to the untrusted Content-Encoding header. The number of decompression layers is capped at 5, but the total decompressed output size is not bounded and there is no option to limit it. A malicious or faulty upstream can return a small compressed payload (a compression bomb) that expands to hundreds of megabytes or gigabytes in client memory, exhausting memory and causing the Node.js …

undici's RetryHandler can leave a response body pending indefinitely. When a retried request receives a non-retryable response after a truncated one, the original response.body held by the application is never settled, so reads such as response.body.text() hang and bodyTimeout does not fire. A malicious server can repeat this to accumulate pending promises and streams, leading to denial of service.

Insufficient clearing of the output buffer in Java-based decompressor implementations in lz4-java 1.10.0 and earlier allows remote attackers to read previous buffer contents via crafted compressed input. In applications where the output buffer is reused without being cleared, this may lead to disclosure of sensitive data. JNI-based implementations are not affected.

Insufficient clearing of the output buffer in Java-based decompressor implementations in lz4-java 1.10.0 and earlier allows remote attackers to read previous buffer contents via crafted compressed input. In applications where the output buffer is reused without being cleared, this may lead to disclosure of sensitive data. JNI-based implementations are not affected.

Insufficient clearing of the output buffer in Java-based decompressor implementations in lz4-java 1.10.0 and earlier allows remote attackers to read previous buffer contents via crafted compressed input. In applications where the output buffer is reused without being cleared, this may lead to disclosure of sensitive data. JNI-based implementations are not affected.

This advisory has been marked as a false positive.

This advisory has been marked as a false positive.

This advisory has been marked as a false positive.

This advisory has been marked as False Positive and has been removed.

After an API Token exposure from an exploited trivy dependency, two new releases of litellm were uploaded to PyPI containing automatically activated malware, harvesting sensitive credentials and files, and exfiltrating to a remote API. Anyone who has installed and run the project should assume any credentials available to litellm environment may have been exposed, and revoke/rotate thema ccordingly.