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).

يوجد خلل في إعادة الدخول (re-entrancy) في وحدة HTTPS يسمح لعميل غير مصرح له بقراءة الذاكرة الخاصة باتصالات أخرى، مما قد يؤدي إلى كشف مفاتيح TLS الخاصة وطلبات مستخدمين آخرين. تحدث المشكلة عندما تستدعي `TLSWrap::DoWrite()` الدالة `ClearOut()` عند طلب كتابة صفر من البايتات من خلال JavaScript داخل callback `on body` الخاص بمحلل HTTP. يؤدي ذلك إلى قيام `ClearOut()` بفك تشفير سجل TLS التالي بينما لا يزال المحلل في منتصف معالجة الجسم، مما يؤدي إلى إعادة الدخول في `llhttp execute()` والتسبب في خطأ use-after-free وقراءة خارج حدود الذاكرة المكدسة (heap). يقوم الخادم بعد ذلك بنسخ تلك الذاكرة المحررة أو غير ذات الصلة في استجابة جسم الطلب. يتطلب استغلال ذلك وجود معالج يستدعي `res.flushHeaders()` قبل انتهاء جسم الطلب، ثم يستدعي `res.end()` بقطعة غير فارغة، مع وجود مسار يقوم بترديد أو تخزين جسم الطلب.

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.

The issue is related to errors in the certificate authentication procedure of the Undici module in Node.js, which can allow a remote attacker to access protected information. Specifically, `Undici.ProxyAgent` never verifies the remote server's certificate and exposes all request and response data to the proxy. This means that proxies can perform man-in-the-middle (MitM) attacks on all HTTPS traffic. If the proxy's URL is HTTP, then nominally HTTPS requests are sent via plain-text HTTP between Undici and the proxy server.