Summary

Out-of-bounds Write vulnerability in the bundled Brotli decoder in yjh0502 erl-brotli allows an attacker who supplies a crafted Brotli-compressed stream to brotli:decode/1 to corrupt decoder state memory, disclose memory contents, crash the Erlang VM, or potentially execute code.

erl-brotli compiles its own copy of the Google Brotli C sources under csrc into a NIF, and brotlidecoderdecompressstream in csrc/brotlinif.c hands the input to BrotliDecoderDecompressStream. In csrc/dec/decode.c, DecodeBlockTypeAndLength returns false for a block switch in a category with at most one block type, and the non-streaming callers DecodeLiteralBlockSwitch, DecodeCommandBlockSwitch and DecodeDistanceBlockSwitch discard that result, so decoding continues with inconsistent state. The decoder runs inside a NIF, so memory corruption or a crash takes down the whole VM rather than the calling process. Because the package carries its own copy of the library, the Brotli version installed on the host does not matter.

This issue affects brotli: from 0.3.0 before 0.3.4.

Impact

An attacker who can get an application to decode a Brotli stream they control, for example an HTTP client that decompresses Content-Encoding: br responses with this package, can crash the Erlang VM and potentially run code inside it.

Impact

undici crashes the client process when a TLS 1.2 server renegotiates after the connection is established and presents a different, CA-trusted certificate whose hostname does not match the requested host. Node.js re-runs hostname verification on the renegotiated handshake and destroys the socket with ERRTLSCERTALTNAMEINVALID. undici's established socket error handler asserted that this error code could never occur, so the peer-controlled error became an uncaught AssertionError that terminates the Node.js process. Both the HTTP/1.1 and HTTP/2 paths are affected.

A malicious or compromised HTTPS endpoint reached through undici or the global fetch() can crash the client with a single server-initiated renegotiation, taking down all in-flight requests and background work in the process. Only TLS 1.2 is affected, because TLS 1.3 does not support renegotiation. Exploitation does not require a CA compromise: the attacker controls the endpoint and can present two ordinary valid certificates, the first matching the requested URL and the second intentionally not matching it.

Patches

Upgrade to undici 6.29.1, 7.30.1, or 8.12.2.

Workarounds

Restrict outbound connections to TLS 1.3, for example by setting connect: { minVersion: 'TLSv1.3', maxVersion: 'TLSv1.3' } on the client or agent, so that renegotiation cannot occur, when the target endpoints support TLS 1.3.

A null pointer dereference flaw was found in openssl. A remote attacker, able to control the arguments of the GENERALNAMEcmp function, could cause the application, compiled with openssl to crash resulting in a denial of service. The highest threat from this vulnerability is to system availability.

A flaw was found in microprocessor execution engine sharing on SMT (e.g. Hyper-Threading) architectures. An attacker running a malicious process on the same core of the processor as the victim process, can extract certain secret information.

The reporter is able to steal an OpenSSL (<= 1.1.0h) P-384 private key from a TLS server using this new side-channel vector. It is a local attack in the sense that the malicious process must be running on the same physical core as the victim (an openSSL-powered TLS server in this case). But in general any application which branches on a secret value may be affected.

References: https://seclists.org/oss-sec/2018/q4/123

HTTP/2 Rapid reset attack The HTTP/2 protocol allows clients to indicate to the server that a previous stream should be canceled by sending a RSTSTREAM frame. The protocol does not require the client and server to coordinate the cancellation in any way, the client may do it unilaterally. The client may also assume that the cancellation will take effect immediately when the server receives the RSTSTREAM frame, before any other data from that TCP connection is processed.

Abuse of this feature is called a Rapid Reset attack because it relies on the ability for an endpoint to send a RSTSTREAM frame immediately after sending a request frame, which makes the other endpoint start working and then rapidly resets the request. The request is canceled, but leaves the HTTP/2 connection open.

The HTTP/2 Rapid Reset attack built on this capability is simple: The client opens a large number of streams at once as in the standard HTTP/2 attack, but rather than waiting for a response to each request stream from the server or proxy, the client cancels each request immediately.

The ability to reset streams immediately allows each connection to have an indefinite number of requests in flight. By explicitly canceling the requests, the attacker never exceeds the limit on the number of concurrent open streams. The number of in-flight requests is no longer dependent on the round-trip time (RTT), but only on the available network bandwidth.

In a typical HTTP/2 server implementation, the server will still have to do significant amounts of work for canceled requests, such as allocating new stream data structures, parsing the query and doing header decompression, and mapping the URL to a resource. For reverse proxy implementations, the request may be proxied to the backend server before the RSTSTREAM frame is processed. The client on the other hand paid almost no costs for sending the requests. This creates an exploitable cost asymmetry between the server and the client.

Multiple software artifacts implementing HTTP/2 are affected. This advisory was originally ingested from the swift-nio-http2 repo advisory and their original conent follows.

swift-nio-http2 specific advisory swift-nio-http2 is vulnerable to a denial-of-service vulnerability in which a malicious client can create and then reset a large number of HTTP/2 streams in a short period of time. This causes swift-nio-http2 to commit to a large amount of expensive work which it then throws away, including creating entirely new Channels to serve the traffic. This can easily overwhelm an EventLoop and prevent it from making forward progress.

swift-nio-http2 1.28 contains a remediation for this issue that applies reset counter using a sliding window. This constrains the number of stream resets that may occur in a given window of time. Clients violating this limit will have their connections torn down. This allows clients to continue to cancel streams for legitimate reasons, while constraining malicious actors.

Calls to EVPCipherUpdate, EVPEncryptUpdate and EVPDecryptUpdate may overflow the output length argument in some cases where the input length is close to the maximum permissable length for an integer on the platform. In such cases the return value from the function call will be 1 (indicating success), but the output length value will be negative. This could cause applications to behave incorrectly or crash. OpenSSL versions 1.1.1i and below are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1j. OpenSSL versions 1.0.2x and below are affected by this issue. However OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2y. Other users should upgrade to 1.1.1j. Fixed in OpenSSL 1.1.1j (Affected 1.1.1-1.1.1i). Fixed in OpenSSL 1.0.2y (Affected 1.0.2-1.0.2x).

A flaw was found in the way the DES/3DES cipher was used as part of the TLS/SSL protocol. A man-in-the-middle attacker could use this flaw to recover some plaintext data by capturing large amounts of encrypted traffic between TLS/SSL server and client if the communication used a DES/3DES based ciphersuite.

Impact

undici's fetch() crashes the Node.js process when a malicious server returns a response with more than five content codings and closes the connection before sending the body. undici rejects such responses (a content-encoding limit), but it created the internal response stream before that check and returned without attaching an error listener or aborting the request. The early close then surfaces a content-length mismatch on that orphaned internal stream, which Node.js treats as an unhandled error and terminates the process. A remote, unauthenticated server can trigger this with a single response, even when the application correctly catches the fetch() rejection. undici 6.x, 7.x, and 8.x are affected.

Patches

Upgrade to 6.29.1, 7.30.1, or 8.12.2. undici now validates the content-encoding chain before creating the internal body stream and aborts the response when the limit is exceeded, so no error can surface on an orphaned stream.

Workarounds

None.

Impact

undici's Agent passes its constructor options through a JSON-based deep clone (JSON.parse(JSON.stringify(...))) before forwarding them to each per-origin Pool. JSON cannot represent functions, so a caller-supplied tls option containing a checkServerIdentity callback 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 chain checks, is silently accepted when the request is made through Agent. Because Agent is the default dispatcher behind request, fetch, and setGlobalDispatcher, this is the path most applications use. EnvHttpProxyAgent is also affected on its direct and NOPROXY routes, which delegate to an internal Agent.

Only applications that pass a function-valued tls option (such as a custom checkServerIdentity for certificate or public-key pinning) are affected. Passing the same options through connect is not affected. This is the Agent counterpart of the BalancedPool certificate validation bypass fixed in CVE-2026-84961.

Patches

Upgrade to undici 6.29.1, 7.30.1, or 8.12.2. Agent now preserves the tls option outside the JSON clone, so custom TLS verification callbacks are forwarded to each origin unchanged.

Workarounds

Pass the TLS options through connect instead of tls. For proxied EnvHttpProxyAgent destinations, use requestTls / proxyTls.

A flaw in Node.js's permission model allows Unix Domain Socket (UDS) connections to bypass network restrictions when --permission is enabled. Even without --allow-net, attacker-controlled inputs (such as URLs or socketPath options) can connect to arbitrary local sockets via net, tls, or undici/fetch. This breaks the intended security boundary of the permission model and enables access to privileged local services, potentially leading to privilege escalation, data exposure, or local code execution.

In the moment of this vulnerability, network permissions (--allow-net) are still in the experimental phase.

A flaw was found in Node.js, where it is vulnerable to a use-after-free attack. This flaw allows an attacker to exploit the memory corruption, which causes a change in the process behavior. The highest threat from this vulnerability is to confidentiality and integrity.

Calling Buffer.fill() or Buffer.alloc() with some parameters can lead to a hang which could result in a Denial of Service.

Impact

The undici WebSocket client enforces maxPayloadSize on the cumulative byte count of fragments in a message but does not enforce a limit on the number of fragments. A malicious WebSocket server can stream many small or empty continuation frames that each pass per-frame and cumulative-size validation, collectively causing unbounded memory growth in the client process. The result is memory exhaustion and a denial of service.

Affected applications are those using the undici WebSocket client (new WebSocket(...)) or the WebSocketStream API that can be induced to connect to an attacker-controlled or compromised WebSocket endpoint.

All releases starting at undici 6.17.0 are affected.

Patches

Upgrade to undici v6.27.0, v7.28.0 or v8.5.0.

Workarounds

No workaround is available. The fix must be applied through an upgrade.

Node.js could allow a remote attacker to bypass security restrictions, caused by the use of the deprecated API process.binding(). By using a path traversal sequence, an attacker could exploit this vulnerability to bypass the permission model.

Last updated 24 July 2024

Impact

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 server, or over a plaintext ws:// connection subject to a machine-in-the-middle. It affects the default new WebSocket(url) usage, where no subprotocol is requested. Per RFC 6455 section 4.1, an unrequested subprotocol must fail the connection, not crash it.

All releases starting at undici 6.7.0 are affected.

Patches

Upgrade to undici 6.28.1, 7.29.1, or 8.10.2.

Workarounds

No workaround is available. The fix must be applied through an upgrade.

Impact

undici's experimental WebSocket client (enabled by default via allowH2: true) crashes the Node.js process when it connects to a malicious server over HTTP/2. If the server answers the WebSocket upgrade with a response that fails handshake validation, undici aborts the request, but the abort is a no-op because the request is already marked completed, so the underlying ClientHttp2Stream is left open with no error listener. When the server then destroys the connection, the orphaned stream emits an unhandled error and the process exits. A remote, unauthenticated server can therefore deny service to any client that opens a WebSocket to it over HTTP/2. undici 8.11.0 and 8.11.1 are affected; the regression was introduced in 8.11.0.

Patches

Upgrade to 8.11.2.

Workarounds

Set allowH2: false to disable HTTP/2 for WebSocket connections, or avoid opening WebSocket connections to untrusted servers, until upgrading.

Impact

When an originless Agent composes the redirect and cache interceptors as compose(redirect(), cache()) with a shared cache (type: 'shared'), the cache builds its key from the original request URL before the redirect handler changes the origin. The response produced after a redirect is then stored under the original key, even when the redirect crossed to a different origin.

An attacker who controls the target of a redirect from a trusted URL can have their response cached under that trusted URL. A later caller requesting the trusted URL receives the attacker's body from the shared cache without either origin being contacted, allowing persistent cache poisoning. The same key confusion also discloses private data: when an authenticated request returns a private, no-store redirect to a user-specific resource, the final response is stored under the original URL and can be served to a later unauthenticated caller.

The cache interceptor was introduced in undici 7.0.0, and all 7.x and 8.x releases before the patched versions are affected. Applications are affected only when an originless Agent, a shared MemoryCacheStore or SqliteCacheStore, and the composition compose(redirect(), cache()) are all used. Origin-bound Client and Pool dispatchers, and the reverse composition compose(cache(), redirect()), are not affected.

Patches

Upgrade to 7.30.1 or 8.12.2. Before storing a response, undici now verifies that the origin that produced it still matches the cache key, and preserves each redirect hop's cache-control policy, so cross-origin redirect responses and responses behind a no-store or private hop are no longer cached under the original key.

Workarounds

Compose the interceptors as compose(cache(), redirect()), use per-origin dispatchers and cache stores, or disable shared caching on redirect-capable requests.

A flaw was found in NodeJS. The issue occurs in the Node.js rebinding protector for --inspect that still allows invalid IP addresses, specifically, the octal format. This flaw allows an attacker to perform DNS rebinding and execute arbitrary code.

A flaw was found in the undici package. When requesting unsanitized input on content-type headers, it is possible to inject additional requests via Carriage Return/Line Feed (CRLF).

A Server-Side Request Forgery (SSRF) vulnerability was found in undici, a HTTP/1.1 client for Node.js. An attacker can manipulate the server-side application to make requests to an unintended location when they use the 'path/pathname' option in 'undici.request'.

A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Note that this occurs after certificate chain signature verification and requires either a CA to have signed a malicious certificate or for an application to continue certificate verification despite failure to construct a path to a trusted issuer. An attacker can craft a malicious email address in a certificate to overflow an arbitrary number of bytes containing the . character (decimal 46) on the stack. This buffer overflow could result in a crash (causing a denial of service).

In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects.

OpenSSL versions 3.0.0 to 3.0.6 are vulnerable to this issue.

All versions of the v18.x and v19.x releases lines.

Description

Undici.ProxyAgent never verifies the remote server's certificate, and always exposes all request & response data to the proxy. This unexpectedly means that proxies can MitM all HTTPS traffic, and if the proxy's URL is HTTP then it also means that nominally HTTPS requests are actually sent via plain-text HTTP between Undici and the proxy server.

Impact

This affects all use of HTTPS via HTTP proxy using Undici.ProxyAgent with Undici or Node's global fetch. In this case, it removes all HTTPS security from all requests sent using Undici's ProxyAgent, allowing trivial MitM attacks by anybody on the network path between the client and the target server (local network users, your ISP, the proxy, the target server's ISP, etc). This less seriously affects HTTPS via HTTPS proxies. When you send HTTPS via a proxy to a remote server, the proxy can freely view or modify all HTTPS traffic unexpectedly (but only the proxy).

Patches

This issue was patched in Undici v5.5.1.

Workarounds

At the time of writing, the only workaround is to not use ProxyAgent as a dispatcher for TLS Connections.

A vulnerability was found in NodeJS due to the llhttp parser in the HTTP module incorrectly handling multi-line Transfer-Encoding headers. This issue can lead to HTTP Request Smuggling (HRS). This flaw allows a remote attacker to send a specially crafted HTTP request to the server and smuggle arbitrary HTTP headers, causing web cache poisoning, and conducting XSS attacks.

A vulnerability was found in NodeJS due to improper validation of HTTP requests. The llhttp parser in the http module does not correctly parse and validate Transfer-Encoding headers. This issue can lead to HTTP Request Smuggling (HRS), causing web cache poisoning, and conducting XSS attacks.

A OS Command Injection vulnerability exists in Node.js versions <14.20.0, <16.20.0, <18.5.0 due to an insufficient IsAllowedHost check that can easily be bypassed because IsIPAddress does not properly check if an IP address is invalid before making DBS requests allowing rebinding attacks.

A vulnerability was found in NodeJS due to the llhttp parser in the http module not strictly using the CRLF sequence to delimit HTTP requests. This issue can lead to HTTP Request Smuggling (HRS). This flaw allows an attacker to send a specially crafted HTTP request to the server and smuggle arbitrary HTTP headers, causing web cache poisoning, and conducting XSS attacks.

A vulnerability was found in NodeJS due to improper validation of HTTP requests. The llhttp parser in the HTTP module in Node.js does not correctly handle header fields that are not terminated with CLRF. This issue may result in HTTP Request Smuggling. This flaw allows a remote attacker to send a specially crafted HTTP request to the server and smuggle arbitrary HTTP headers.

A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Note that this occurs after certificate chain signature verification and requires either a CA to have signed the malicious certificate or for the application to continue certificate verification despite failure to construct a path to a trusted issuer. An attacker can craft a malicious email address to overflow four attacker-controlled bytes on the stack. This buffer overflow could result in a crash (causing a denial of service) or potentially remote code execution.

Many platforms implement stack overflow protections which would mitigate against the risk of remote code execution. The risk may be further mitigated based on stack layout for any given platform/compiler.

Pre-announcements of CVE-2022-3602 described this issue as CRITICAL. Further analysis based on some of the mitigating factors described above have led this to be downgraded to HIGH. Users are still encouraged to upgrade to a new version as soon as possible.

In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects.

A vulnerability was found in NodeJS due to weak randomness in the WebCrypto keygen within the SecretKeyGenTraits::DoKeyGen() in src/crypto/cryptokeygen.cc. Node.js made calls to EntropySource() in SecretKeyGenTraits::DoKeyGen(). However, it does not check the return value and assumes the EntropySource() always succeeds, but it can and sometimes will fail. This flaw allows a remote attacker to decrypt sensitive information.