Vulnerability Spoiler Alert

 Today’s Briefing

155

Total Findings

47

Confirmed CVEs

64

Verified

Unverified

41

False Positives

HIGH: 65 MEDIUM: 43 LOW: 6

47 CVE matched

35 found before CVE

2 avg lead (days)

27 max lead (days)

HIGH<br>UNVERIFIED<br>Missing Certificate Hostname Verification (Improper Certificate Validation)

May 25, 2026, 02:14 AM — nodejs/node

Commit: 2e3daf6e4dd50e3f4f279f443acaf727fd817ca8

Author: James M Snell

Before this patch, the Node.js QUIC implementation did not call SSL_set1_host() to enable OpenSSL's hostname verification against the server certificate's SAN/CN fields. This meant that a QUIC client in 'strict' or 'auto' verifyPeer modes would accept any valid certificate (signed by a trusted CA) regardless of which hostname it was issued for, enabling man-in-the-middle attacks. The patch adds SSL_set1_host() calls via a new set_verify_hostname() method, ensuring the server's certificate actually matches the intended servername.

 View Affected Code & PoC<br>Affected Code<br>// Before patch: verifyHostname option did not exist<br>// In processSessionOptions, only verifyPeerStrict was set:<br>verifyPeerStrict: verifyPeer === 'strict',<br>// No verifyHostname field — SSL_set1_host() was never called<br>Proof of Concept<br>// Attacker scenario: MitM attack against a QUIC client connecting to example.com<br>// 1. Attacker obtains a valid TLS cert for attacker.com (trusted CA signed)<br>// 2. Attacker intercepts the QUIC connection<br>// 3. Before patch: the client accepts attacker.com's cert when connecting to example.com<br>// because hostname verification (SSL_set1_host) was never configured<br>// Node.js code that would be vulnerable (before patch):<br>const { QuicEndpoint } = require('node:quic');<br>const endpoint = new QuicEndpoint();<br>// Connect to example.com:443 with verifyPeer='strict'<br>// Before patch: connection succeeds even if server presents cert for attacker.com<br>// (as long as it's signed by a trusted CA), allowing full MitM<br>const session = await endpoint.connect({<br>address: 'attacker-controlled-ip',<br>port: 443,<br>servername: 'example.com',<br>verifyPeer: 'strict',<br>});<br>// Would succeed with attacker.com certificate before patch

View Issue #192

HIGH<br>UNVERIFIED<br>Resource Exhaustion / Denial of Service (Slowloris-style attack)

May 25, 2026, 02:14 AM — nodejs/node

Commit: 866caa61f3b8f3a6f4f3e0ebb28ced0953ef3431

Author: James M Snell

Before this patch, peer-initiated QUIC streams had no idle timeout mechanism. A remote attacker could open many streams without sending any data, holding server resources (memory, stream state) indefinitely. This is a slowloris-style resource exhaustion attack. The patch adds a configurable `streamIdleTimeout` (defaulting to 30 seconds) that automatically destroys peer-initiated streams that have been idle beyond the timeout threshold.

 View Affected Code & PoC<br>Affected Code<br>// No stream idle timeout existed. Peer-initiated streams could remain open indefinitely with no data sent, consuming server resources without bound.<br>Proof of Concept<br>// Attacker opens many QUIC streams and never sends data:<br>import quic from 'node:quic';<br>const client = await quic.connect({ address: 'victim-server', port: 4433 });<br>// Open thousands of streams but never write to them:<br>for (let i = 0; i

View Issue #193

⚠️<br>MEDIUM<br>UNVERIFIED<br>Connection Hijacking / Data Exfiltration via QUIC Preferred Address

May 25, 2026, 02:14 AM — nodejs/node

Commit: 444ba160e3581b28762d1d456dd6d7fc86de5d18

Author: James M Snell

The default policy for QUIC preferred address handling was 'use' (or mapped to USE_PREFERRED), meaning clients would automatically migrate their connection to whatever IP address a server advertised as its preferred address. A malicious server could advertise a preferred address pointing to an attacker-controlled host, causing the client to redirect its QUIC connection traffic to that address — enabling data exfiltration that is indistinguishable from legitimate QUIC connection migration at the network level. The patch changes the default to 'ignore', so clients only migrate when explicitly configured to do so with preferredAddressPolicy: 'use'.

 View Affected Code & PoC<br>Affected Code<br>preferredAddressPolicy = 'default',<br>// and in preferredaddress.cc:<br>static constexpr auto DEFAULT_PREFERRED_ADDRESS_POLICY =<br>static_cast(Policy::USE_PREFERRED);<br>Proof of Concept<br>// Attacker sets up a malicious QUIC server that advertises a preferred address<br>// pointing to an attacker-controlled endpoint:<br>// 1. Victim connects to legitimate-looking server (e.g., port 443)<br>// 2. Server responds with preferred_addr transport parameter pointing to attacker's IP<br>// 3. With the old default ('use'), the Node.js QUIC client automatically migrates<br>// to the attacker's address, sending all subsequent application data there<br>//<br>// Example: attacker server sends ngtcp2_transport_params with:<br>// params.preferred_addr_present = 1;<br>// params.preferred_addr.ipv4_present = 1;<br>// // attacker IP: 192.168.1.100:9999<br>//...