Pimterry

A deferred-callback use-after-destroy in Node.js TLS server handshake handling allows a remote, unauthenticated attacker to terminate the server process. When a TLS server uses any of the SNICallback, OCSPRequest, newSession, or resumeSession hooks, or server.addContext(), the corresponding OpenSSL callbacks are deferred, and the deferred code does not handle the underlying socket being destroyed between scheduling and execution. By sending a client hello that reaches the vulnerable path (for example, no SNI together with an OCSP request) followed by padding and a socket FIN, an attacker makes OpenSSL deliver the client hello and the end-of-file in the same tick, so the socket is destroyed before the deferred callback runs and the process raises an uncaught exception instead of emitting an 'error' event. This vulnerability affects Node.js 26.x and 24.x.

A one-byte heap buffer overflow in Node.js HTTP/2 Alt-Svc handling lets a remote, unauthenticated attacker corrupt process memory. When an application passes an attacker-controlled value such as a request's :authority header to Http2Session.altsvc(), the AltSvc implementation in src/node http2.cc allocates a buffer sized to the origin length and then writes it with a null terminator, placing one byte past the end of the allocation. A single request carrying a long but syntactically valid :authority triggers the out-of-bounds write, which aborts the process and serves as a remote heap-corruption primitive. This vulnerability affects Node.js 26.x and 24.x.

A reachable assertion in Node.js HTTP/2 session teardown lets any unauthenticated client abort the server, over both TLS and cleartext. A client can arrange for an Http2Stream that still holds nghttp2-allocated header buffers to outlive its session: the stream is removed from the session's stream set but never detached, so when ~Http2Session() runs the memory accounting is nonzero and the CHECK EQ(current nghttp2 memory , 0) assertion fails, terminating the process. The trigger needs only a default http2 server whose handler responds before the request body has ended, which is typical. It is a variant of CVE-2024-27983 that the earlier fix did not cover, because that fix only detached streams still tracked in the session. This vulnerability affects Node.js 26.x (since 26.9.0) and 24.x (since 24.22.0).

Uma falha de reentrada no módulo HTTPS permite que um cliente não autenticado leia a memória de outras conexões, expondo potencialmente chaves privadas TLS e requisições de outros usuários. O problema ocorre quando `TLSWrap::DoWrite()` chama `ClearOut()` durante uma solicitação de gravação de zero bytes emitida pelo JavaScript dentro do callback `on body` do parser HTTP. Isso faz com que `ClearOut()` decifre o próximo registro TLS enquanto o parser ainda está processando o corpo, reentrando em `llhttp execute()` e resultando em um use-after-free e uma leitura de heap fora dos limites. Consequentemente, o servidor copia a memória do heap liberada ou não relacionada para o corpo da resposta. A exploração requer um manipulador que chame `res.flushHeaders()` antes do término do corpo da requisição e, posteriormente, chame `res.end()` com um chunk não vazio, juntamente com uma rota que ecoe ou armazene o corpo de uma requisição.

An unauthenticated HTTP/2 client can permanently leak Node.js server memory and file descriptors. If a peer triggers a protocol error, for example an oversized frame header, while the session is already shutting down, nghttp2 tears the session down internally but Node.js never notices, leaving a dangling session: the socket stays in CLOSE WAIT and all of Node.js's HTTP/2 state for that connection is held in memory indefinitely, with no further cost to the attacker. The attacker can start the shutdown remotely by sending GOAWAY(NO ERROR), so it is reliable against default HTTP/2 servers. It is an incomplete-fix case of CVE-2026-48937: that fix detected nghttp2 internal terminations by watching for GOAWAY sent while not shutting down, but missed terminations that arrive while the session is already shutting down. This vulnerability affects Node.js 26.x, 24.x, and 22.x.

A per-host mutual-TLS authorization bypass in Node.js lets a client authorized for the default hostname reach a protected hostname it is not authorized for. When a TLS server assigns a hostname a different client-certificate CA with server.addContext(host, { ca: protectedCA }) but no server certificate in that SNI context, the per-host client CA is never installed and the handshake falls back to the default client CA. In src/crypto/crypto tls.cc, CertCbDone installs the SNI context's CA only when setSniContext succeeds, but setSniContext returns false for a context with no server certificate, so a CA-only SNI context silently keeps the default CA. A client holding a certificate trusted by the default CA, but not the protected CA, can therefore complete mTLS to the protected hostname and read its response even with requestCert and rejectUnauthorized enabled, while a client certified by the protected CA is rejected. This vulnerability affects Node.js 26.x, 24.x, and 22.x.

A client certificate authentication bypass in Node.js TLS lets a client change the servername during TLS 1.2 renegotiation to reach endpoints it was not authorized for. On a server that applies different client-certificate policies per hostname, for example stricter admin-only client-cert auth on one host and ordinary client-cert auth on another, a client that authenticates for a permitted host can renegotiate the TLS 1.2 connection under a different servername and carry its existing authentication to the protected host, bypassing the stricter policy. This vulnerability affects Node.js 26.x, 24.x, and 22.x.

O problema está relacionado a erros no procedimento de autenticação de certificados do módulo Undici no Node.js, o que pode permitir que um invasor remoto acesse informações protegidas. Especificamente, o `Undici.ProxyAgent` nunca verifica o certificado do servidor remoto e expõe todos os dados de solicitação e resposta ao proxy. Isso significa que os proxies podem realizar ataques man-in-the-middle (MitM) em todo o tráfego HTTPS. Se a URL do proxy for HTTP, então, nominalmente, as solicitações HTTPS são enviadas via HTTP em texto simples entre o Undici e o servidor proxy.