TightVNC Server EUVD-2026-94978

Requires a local authenticated user (PR:L, AV:L) on the Windows host running TightVNC Server before 2.8.88, and the server must be using the DXGI screen-capture path (the default capture mechanism on modern Windows). The specific trigger is a cursor shape reaching trimTransparent() with width or height of zero - including a monochrome cursor of height 1, which getCursorHeight() halves in place to 0. Limiting factors that reduce realistic risk: no remote/network vector, an authenticated local session is mandatory, the condition is tied to the DXGI capture path specifically, and the primary outcome is a crash rather than confirmed data disclosure.

This is a medium-severity, low-real-world-priority issue despite the memory-corruption flavor. All exploitation signals point low: the CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H, score 6.1) requires LOCAL access and an authenticated local user (PR:L), so there is no network-facing exposure. CISA's SSVC decision framework reinforces this - Exploitation: none, Automatable: no, Technical Impact: partial - meaning no observed exploitation and no mass-scaling potential. No EPSS score was provided in the input and the CVE is NOT in CISA KEV, so there is no evidence of active exploitation. No public exploit code was identified at time of analysis. The dominant impact is availability (A:H, a server crash via the integer underflow wrapping width-1 to 0xFFFFFFFF); the confidentiality impact is only Low (C:L) because the ~4 GB out-of-bounds access beyond the 64 KB cursor buffer will almost certainly fault and crash rather than return attacker-usable data, making a reliable OOB read speculative. Signals are internally consistent - there is no CVSS-vs-description conflict here (the description explicitly says 'local authenticated user', matching AV:L/PR:L). Bottom line: a legitimate but low-priority DoS bug that a local authenticated user could trigger; patch during normal maintenance cycles rather than emergency.

A local authenticated user on the Windows host running TightVNC Server causes a cursor shape with a width or height of zero (or a monochrome cursor of height 1, which getCursorHeight() halves to 0) to be captured on the DXGI path. The integer underflow in trimTransparent() wraps the loop bound to 0xFFFFFFFF, driving an access roughly 4 GB past the 64 KB cursor buffer that crashes the server and may expose out-of-bounds memory. No public exploit code was identified at time of analysis.