CVE-2026-107611 in TightVNC
Summary
by MITRE • 10/08/2026
An out-of-bounds read vulnerability in the ZRLE decoder of GlavSoft TightVNC Viewer for Windows before 2.8.88 allows a malicious or compromised VNC server to read heap memory beyond the palette allocation and crash the viewer by sending ZRLE-encoded tiles whose palette indices exceed the declared palette size. readPaletteRleTile() and readPackedPaletteTile() use the attacker-supplied index to look up colours without validating it against the palette size; out-of-bounds heap data is copied into the framebuffer (garbled display) or the read faults, terminating the viewer.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/08/2026
The vulnerability identified in GlavSoft TightVNC Viewer for Windows prior to version 2.8.88 represents a critical security flaw within its remote desktop protocol implementation, specifically affecting the ZRLE compression decoder. This out-of-bounds read issue arises from insufficient validation of input data provided by the VNC server during the rendering process. The core technical defect lies in the functions responsible for processing palette-based raster operations, namely readPaletteRleTile and readPackedPaletteTile. These internal routines are designed to map color indices to actual pixel values within a defined palette structure. However, they fail to perform boundary checks on the index values supplied by the remote server before attempting to access memory locations associated with those indices.
When an attacker controls or compromises the VNC server, they can craft malicious ZRLE-encoded tiles that contain palette indices exceeding the declared size of the color palette allocated for the current session. Upon receiving such a tile, the viewer's decoder processes it without verifying whether the index falls within the valid range of the pre-allocated memory buffer. Consequently, the application attempts to read heap memory located beyond the bounds of the intended palette array. This action results in an out-of-bounds read operation, which can lead to two distinct failure modes depending on the specific memory layout and operating system protections at play. In some instances, the invalid data is copied into the framebuffer, resulting in a garbled or corrupted display output that may leak sensitive information from adjacent heap regions if further processing occurs.
In more severe scenarios, particularly when accessing unmapped or protected memory pages, this out-of-bounds read triggers an access violation exception. This fault causes the TightVNC Viewer process to terminate abruptly, leading to a denial of service condition for the user attempting to connect via VNC. The impact is primarily localized to availability and potential information disclosure through side-channel effects if the leaked heap data contains sensitive context from other applications or system processes sharing the same memory space. This vulnerability aligns with CWE-125, which describes out-of-bounds read vulnerabilities where software reads past the end of a buffer. Furthermore, in the context of attack vectors, this flaw can be exploited via ATT&CK technique T1498, Network Denial of Service, as it allows an adversary to disrupt service availability by crashing the client application through crafted network packets.
Mitigation strategies for this vulnerability involve immediate patching of the TightVNC Viewer software to version 2.8.88 or later, where these boundary checks have been implemented in the decoding routines. Administrators should ensure that all endpoints running older versions are updated promptly. Additionally, deploying network-level access controls can limit exposure by restricting VNC connections to trusted sources only, thereby reducing the attack surface for compromised servers attempting to exploit this flaw. Security monitoring tools may also be configured to detect anomalous patterns in VNC traffic indicative of malformed ZRLE tiles, although direct patching remains the most effective remediation step given the nature of the client-side execution error.