CVE-2026-32853: 
NixOS vulnerability analysis and mitigation

CVE-2026-32853 is a heap out-of-bounds read vulnerability in LibVNCServer's UltraZip encoding handler, specifically in the HandleUltraZipBPP() function within src/libvncclient/ultra.c. It affects LibVNCServer versions 0.9.15 and prior and was disclosed on March 24, 2026, with a fix available in commit 009008e. A malicious VNC server can exploit improper bounds checking by manipulating subrectangle header counts to cause information disclosure or application crash. It carries a CVSS v3.1 base score of 8.1 (High) and a CVSS v4.0 base score of 6.9 (Medium) (GitHub Advisory, Red Hat Bugzilla).

The root cause is an out-of-bounds read (CWE-125) in HandleUltraZipBPP() in ultra.c. The outer rectangle header field rect.r.x is used directly as numCacheRects (the subrectangle count) without any validation, allowing an attacker-controlled value to drive the subrectangle parsing loop. Each loop iteration advances a ptr pointer by at least 12 bytes via memcpy calls for subrect header fields, and then further by the raw pixel data size — neither advance is bounds-checked against the decompressed data buffer. A malicious VNC server can set numCacheRects to a large value (e.g., 10,000), causing the client to read tens of kilobytes beyond the allocated heap buffer. UltraZip encoding is registered by default in SetFormatAndEncodings(), and no server-side authentication is required to trigger the flaw (GitHub Advisory, Patch Commit).

Successful exploitation allows a malicious VNC server to read up to tens of kilobytes of heap memory beyond the allocated buffer in any connecting LibVNCClient-based application, potentially exposing sensitive data from adjacent heap allocations (confidentiality impact). Additionally, reading unmapped memory can cause the client application to crash, resulting in denial of service (availability impact). There is no integrity impact, and the vulnerability is scoped to the vulnerable client system without lateral movement to subsequent systems (GitHub Advisory, Red Hat Bugzilla).

No confirmed in-the-wild exploitation has been observed, and no weaponized exploit code is publicly available — the VulnCheck advisory describes the vulnerability mechanics but contains no actionable exploit (VulnCheck Advisory). The GitHub security advisory includes a detailed proof-of-concept description outlining how to set up a malicious VNC server to trigger the flaw, but no ready-to-run exploit script has been published (GitHub Advisory). The EPSS score is approximately 0.04%, indicating low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported.

1. Set up a malicious VNC server: Configure a rogue VNC server advertising RFB protocol version 3.8 with security type rfbSecTypeNone (type 1, no authentication required).
2. Send a crafted ServerInit message: Respond to the connecting LibVNCClient with a ServerInit message specifying arbitrary framebuffer dimensions (e.g., 100×100).
3. Wait for client connection: Allow a LibVNCClient-based VNC viewer to connect to the malicious server.
4. Send a malicious FramebufferUpdate: Transmit a FramebufferUpdate message containing one rectangle with the following fields:
   • rect.encoding = 0xFFFF0009 (rfbEncodingUltraZip)
   • rect.r.x = 10000 (interpreted as numCacheRects — the attacker-controlled subrectangle count)
   • rect.r.y = 100, rect.r.w = 1, rect.r.h = 0
5. Append a minimal LZO-compressed payload: Follow the rectangle header with a small valid LZO-compressed stream (e.g., ~120 bytes of decompressed data), which the client decompresses into raw_buffer (~66 KB).
6. Trigger out-of-bounds read: The client enters the subrect parsing loop, iterating 10,000 times × 12 bytes = 120,000 bytes, reading approximately 54 KB beyond the buffer boundary — leaking heap memory or crashing the client (GitHub Advisory).

• Network: Unexpected inbound VNC connections from untrusted or unknown IP addresses; VNC traffic (typically TCP port 5900) originating from servers not in the organization's approved VNC server list; connections to VNC servers advertising rfbSecTypeNone (no authentication).
• Logs: Application crash logs or core dumps from LibVNCClient-based applications (e.g., segmentation faults in ultra.c); log entries containing UltraZip: subrect header exceeds decompressed data bounds (generated by the patched version when detecting the attack).
• Process: Unexpected termination or crash of VNC client processes; VNC client processes generating core dump files in unexpected directories.

The fix is available in LibVNCServer commit 009008e2f4d5a54dd71f422070df3af7b3dbc931, which adds bounds checks before reading the 12-byte subrect header and before advancing the pointer by raw pixel data size, and uses uint64_t for raw data size calculations to prevent integer overflow on 32-bit platforms (Patch Commit). Users should update LibVNCServer to a version incorporating this commit. As a network-level workaround, restrict which VNC servers client applications are permitted to connect to, and avoid connecting to untrusted or unauthenticated VNC servers. OpenSUSE and Amazon Linux 2 have issued updated packages addressing this vulnerability (OpenSUSE Security, Amazon Linux).

The vulnerability was assigned and disclosed by VulnCheck and published via the LibVNC GitHub Security Advisory on March 24, 2026 (GitHub Advisory). Red Hat tracked the issue via Bugzilla and rated it medium severity (Red Hat Bugzilla). German Linux news outlet Pro-Linux.de covered the vulnerability as part of broader LibVNCServer security reporting. OpenSUSE included the fix in its Tumbleweed March 2026 monthly update and issued a security announcement. No significant social media controversy or notable researcher commentary beyond standard advisory coverage has been observed.