UltraVNC EUVD-2026-40884

Exploitation requires the victim to actively initiate an outbound UltraVNC viewer connection to an attacker-controlled endpoint - either a malicious VNC server or a man-in-the-middle positioned on the RFB stream (UI:P, passive user interaction). No authentication is needed (PR:N): the vulnerable rfbConnFailed and rfbVncAuthFailed message paths execute before any successful auth, so the attacker never needs valid VNC credentials. The concrete trigger is a server-supplied CARD32 reasonLen of 0xFFFFFFFF in the RFB failure-response path. Limiting factors: this is not a server-side listener bug, so it cannot be triggered by unsolicited inbound scanning - the attacker must lure the viewer or control the network path; exploitation is confined to the viewer/client component (versions through 1.8.2.2), and RCE beyond the confirmed heap-corruption crash is potential rather than demonstrated.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H, score 8.7) is internally consistent with the description: network-reachable, low complexity, no privileges, but requiring passive user interaction (UI:P) because the victim must initiate an outbound viewer connection. This is a client-side/reverse-direction vulnerability - the attacker does not scan and hit a listening service; instead the victim's viewer must connect to a malicious server or traverse an attacker-controlled network path, which meaningfully narrows opportunistic mass exploitation. No EPSS score, KEV listing, or SSVC decision was provided in the input, so probabilistic and automatable signals are unavailable and cannot be asserted. The counterweight is that the researcher independently reproduced a controlled heap-buffer-overflow write under AddressSanitizer, confirming the memory-safety defect is real and triggerable pre-auth; RCE is described as potential rather than demonstrated. Net: a genuine high-severity client-side memory-corruption issue, but real-world risk depends on luring or MITM-ing viewer connections rather than default exposure, favoring targeted over widespread exploitation.

An attacker stands up a malicious VNC server (or interposes as a man-in-the-middle on an existing RFB session) and induces a victim to point their UltraVNC viewer at it - for example via a support link, a spoofed internal host, or ARP/DNS redirection. During the pre-authentication handshake the server returns an rfbConnFailed or rfbVncAuthFailed message with reasonLen=0xFFFFFFFF, overflowing the size calculation and writing past a 256-byte heap buffer in the victim's viewer, corrupting the heap toward code execution as the connecting user. The heap-buffer-overflow write was confirmed with AddressSanitizer, though a public weaponized exploit is not identified.