CVE-2026-34352: 
NixOS vulnerability analysis and mitigation

CVE-2026-34352 is an incorrect permission assignment vulnerability in TigerVNC's x0vncserver component, specifically in unix/x0vncserver/Image.cxx. The flaw allows other local (and potentially remote) users to observe or manipulate screen contents, or crash the application. It affects all TigerVNC versions before 1.16.2 and was publicly disclosed on March 26, 2026, following an initial failed fix in version 1.16.1. The NVD-assigned CVSS v3.1 base score is 9.8 (Critical), while ENISA's assessment yields 8.5 (High) (Openwall OSS-Security, GitHub Commit, ENISA EUVD).

The root cause is CWE-732 (Incorrect Permission Assignment for Critical Resource). In ShmImage::Init() within unix/x0vncserver/Image.cxx, the shmget() call allocates a SysV shared memory segment for the framebuffer with world-accessible permissions (IPC_CREAT|0777) instead of owner-only permissions (IPC_CREAT|0600). This means any local user on the same host can attach to the live framebuffer shared memory segment after x0vncserver completes an RFB handshake and begins desktop capture. The fix is a single-line change replacing 0777 with 0600, and notably the viewer-side XShm path in the same codebase already used the correct 0600 permissions — only the server-side capture path was vulnerable (GitHub Issue #2079, GitHub Commit, Openwall OSS-Security).

Exploitation allows an unprivileged local user to attach to the world-readable/writable SysV shared memory segment used as the live framebuffer backing store for x0vncserver. This results in full confidentiality loss (screen contents visible to any local user), integrity compromise (an attacker can modify what is sent to the VNC client), and availability impact (a malicious attacker can crash x0vncserver by timing modifications to the shared memory). The vulnerability is particularly sensitive in multi-user environments such as shared Linux servers or virtual desktop infrastructure where multiple users share the same host (GitHub Issue #2079, Feedly).

No public proof-of-concept exploit code has been identified, and there is no evidence of in-the-wild exploitation at this time. The EPSS score is approximately 0.01% (0.000100), indicating a very low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. However, exploitation requires only local access to the same host running x0vncserver and no special privileges — an attacker simply needs to use standard ipcs/shmat system calls to attach to the world-accessible shared memory segment after x0vncserver starts capturing (Feedly, GitHub Issue #2079).

1. Reconnaissance: Identify systems running x0vncserver on a shared Linux host. Confirm the vulnerable version (before 1.16.2) using x0vncserver --version or package manager queries.
2. Trigger framebuffer allocation: Wait for or cause x0vncserver to begin an active RFB session (e.g., connect a VNC client to initiate the handshake), which triggers ShmImage::Init() and allocates the world-accessible shared memory segment.
3. Enumerate shared memory segments: Run ipcs -m to list SysV shared memory segments. Identify newly created segments owned by the x0vncserver process with permissions 0777 and sizes consistent with the display resolution (e.g., width * height * bytes_per_pixel).
4. Attach to the segment: Use a simple program calling shmat() with the identified shmid to attach to the framebuffer segment. No elevated privileges are required.
5. Read or manipulate screen contents: Read raw pixel data from the attached segment to observe screen contents, write modified pixel data to manipulate what the VNC client receives, or corrupt the segment at a critical moment to crash x0vncserver (GitHub Issue #2079, GitHub Commit).

• Process: Unexpected processes (other than x0vncserver and its legitimate clients) with shmat() calls attaching to shared memory segments owned by the x0vncserver user.
• System IPC: Output of ipcs -m showing SysV shared memory segments with perms 777 and sizes matching display resolution (e.g., 1920000 bytes for 800×600×4bpp), owned by the x0vncserver process owner, with nattch count higher than expected (more than 1–2 legitimate attachments).
• Logs: Unexpected x0vncserver crashes or restarts logged in system journals (journalctl -u x0vncserver or /var/log/syslog), which may indicate timing-based memory corruption attempts.
• Network: Unexpected VNC connections (port 5900/5999) from unknown local or remote IP addresses initiating RFB handshakes to trigger framebuffer allocation (GitHub Issue #2079).

Upgrade TigerVNC to version 1.16.2 or later, which corrects the shared memory permissions from 0777 to 0600 in unix/x0vncserver/Image.cxx. Note that version 1.16.1 was released as a security fix but inadvertently omitted the actual security patch — only 1.16.2 contains the correct fix. Stable binaries are available from SourceForge. As a workaround where upgrading is not immediately possible: restrict access to systems running x0vncserver to trusted users only, implement network segmentation to limit VNC service exposure, and consider disabling x0vncserver if not actively required. Patches are also available through downstream distributions including SUSE, Red Hat, Amazon Linux, Oracle Linux, AlmaLinux, Rocky Linux, and Mageia (Openwall OSS-Security, GitHub Commit, Red Hat Advisory).

The TigerVNC development team (Pierre Ossman, Cendio AB) issued two rapid releases — 1.16.1 and then 1.16.2 — after the first release accidentally omitted the security fix, prompting an apology to the community for the confusion. Alan Coopersmith of Oracle noted the simplicity of the fix on the oss-security mailing list, highlighting the single-line permission change. The vulnerability received coverage from The Hacker Wire and was discussed on Mastodon and Bluesky. Multiple Linux distributions (SUSE, Red Hat, Amazon Linux, Mageia) issued security advisories and updated packages within days of the disclosure (Openwall OSS-Security, The Hacker Wire, TigerVNC Announce).