Engine.IO CVE-2026-102599

Exploitable against Engine.IO/Socket.IO servers that ALLOW TRANSPORT UPGRADES (the default), running affected engine.io 6.6.0-6.6.9 on the default v4 protocol. The attacker needs no authentication (PR:N) and no user interaction, but must first complete a normal Engine.IO handshake to obtain a valid session id, then send an upgrade request whose EIO query parameter differs from or omits the session's negotiated revision (an omitted EIO is interpreted as v3 on the upgrade path, so the bug fires even when explicit v3 compatibility/allowEIO3 is disabled). Limiting factors: the vulnerable upgrade path is neutralized if the deployment sets allowUpgrades:false or restricts transports to WebSocket-only, or if a proxy/middleware rejects existing-sid requests with a missing/mismatched EIO parameter; impact is confined to crashing the Node.js worker process, so damage scale depends on process-restart tooling and how many clients share the process.

This is a genuine, credible availability risk despite the absence of exploitation telemetry. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, base 7.5) aligns tightly with the described mechanics: an unauthenticated remote client can establish a normal Engine.IO session and then crash the entire Node.js process by sending a mismatched-protocol upgrade request that triggers an uncaught exception (CWE-248). Confidentiality and integrity are untouched - this is availability-only. No EPSS score, KEV listing, POC, or SSVC decision data were provided, so exploitation status is 'no public exploit identified at time of analysis'; however, the crash path is well-documented in the vendor advisory and the fix commit, and the exploitation primitive (a crafted query parameter plus a heartbeat packet) is low-effort to reverse-engineer from the public patch, so the practical barrier is low. The signals are consistent rather than conflicting: high CVSS is driven purely by A:H reachable pre-auth, which matches the description. The main factor tempering real-world priority is that a single crash affects one process; impact depends on whether the deployment auto-restarts (e.g. PM2/Kubernetes) and how many other clients share that process - a determined attacker can loop the crash to sustain an outage. Overall this is a real priority for any internet-facing Socket.IO/Engine.IO deployment on an affected version, not a paper-high score.

A malicious client opens a legitimate Engine.IO session over HTTP long-polling (negotiating protocol v4), then issues a WebSocket upgrade request to the same session id but with the EIO query parameter changed or omitted, causing the server to attach a transport whose parser/heartbeat behavior mismatches the session. The attacker then sends a crafted heartbeat packet that the mismatched parser mishandles, raising an uncaught exception that terminates the Node.js process and takes down all connections served by it. No public exploit code was identified at time of analysis, but the vendor patch and test case make the trigger straightforward to reconstruct.