See how tigervnc compares to other vendors in security performance
In TigerVNC before 1.16.2, Image.cxx in x0vncserver allows other users to observe or manipulate the screen contents, or cause an application crash, because of incorrect permissions.
In TigerVNC before 1.16.2, Image.cxx in x0vncserver allows other users to observe or manipulate the screen contents, or cause an application crash, because of incorrect permissions.
I don't see a CVE id listed, but the fix appears to be pretty simple:
shminfo->shmid = shmget(IPCPRIVATE, xim->bytesperline xim->height, - IPCCREAT|0777); + IPCCREAT|0600);
https://github.com/TigerVNC/tigervnc/commit/0b5cab169d847789efa54459a87659d3fd484393
-------- Forwarded Message -------- Subject: [tigervnc-announce] TigerVNC 1.16.1 Date: Wed, 25 Mar 2026 09:59:26 +0100 From: Pierre Ossman <ossman () cendio se> Organization: Cendio AB To: tigervnc-announce () googlegroups com
The bug fix release TigerVNC 1.16.1 is now available. This release is primarily a security release to fix an issue in x0vncserver, where other users can observe and manipulate the screen contents. Users of x0vncserver are advised to update immediately.
The release also contains a fix for using the Plain security type with the new w0vncserver, as well as some translation updates.
Binaries are available from SourceForge:
https://sourceforge.net/projects/tigervnc/files/stable/1.16.1
Regards The TigerVNC Developers
-------- Forwarded Message -------- Subject: [tigervnc-announce] TigerVNC 1.16.2 Date: Thu, 26 Mar 2026 21:49:34 +0100 From: Pierre Ossman <ossman () cendio se> Organization: Cendio AB To: tigervnc-announce () googlegroups com
This is a second attempt at a bug fix release for the security issue in x0vncserver. The TigerVNC 1.16.1 release unfortunately had all fixes except the security fix.
Apologies for the extra noise and confusion.
Binaries are available from SourceForge:
https://sourceforge.net/projects/tigervnc/files/stable/1.16.2
Regards The TigerVNC Developers
-- You received this message because you are subscribed to the Google Groups "TigerVNC Announcements" group. To unsubscribe from this group and stop receiving emails from it, send an email to tigervnc-announce+unsubscribe () googlegroups com. To view this discussion visit https://groups.google.com/d/msgid/tigervnc-announce/dcedc354-d653-4354-b281-cfd9f58139be%40cendio.se.
A flaw was found in the RandR extension, where the RRChangeProviderProperty function does not properly validate input. This issue leads to an integer overflow when computing the total size to allocate.
A flaw was found in the X Record extension. The RecordSanityCheckRegisterClients function does not check for an integer overflow when computing request length, which allows a client to bypass length checks.
A flaw was found in the X server's request handling. Non-zero 'bytes to ignore' in a client's request can cause the server to skip processing another client's request, potentially leading to a denial of service.
A flaw was found in the XFIXES extension. The XFixesSetClientDisconnectMode handler does not validate the request length, allowing a client to read unintended memory from previous requests.
A flaw was found in the Big Requests extension. The request length is multiplied by 4 before checking against the maximum allowed size, potentially causing an integer overflow and bypassing the size check.
A flaw was found in the X Rendering extension's handling of animated cursors. If a client provides no cursors, the server assumes at least one is present, leading to an out-of-bounds read and potential crash.
A heap overflow flaw was found in X.Org and Xwayland. The computation of the length in XkbSizeKeySyms() differs from what is written in XkbWriteKeySyms(), which may lead to a heap-based buffer overflow.
A buffer overflow flaw was found in X.Org and Xwayland. If XkbChangeTypesOfKey() is called with a 0 group, it will resize the key symbols table to 0 but leave the key actions unchanged. If the same function is later called with a non-zero value of groups, this will cause a buffer overflow because the key actions are of the wrong size.
A buffer overflow flaw was found in X.Org and Xwayland. The code in XkbVModMaskText() allocates a fixed-sized buffer on the stack and copies the names of the virtual modifiers to that buffer. The code fails to check the bounds of the buffer and would copy the data regardless of the size.
A use-after-free flaw was found in X.Org and Xwayland. When a device is removed while still frozen, the events queued for that device remain while the device is freed. Replaying the events will cause a use-after-free.
An access to an uninitialized pointer flaw was found in X.Org and Xwayland. The function compCheckRedirect() may fail if it cannot allocate the backing pixmap. In that case, compRedirectWindow() will return a BadAlloc error without validating the window tree marked just before, which leaves the validated data partly initialized and the use of an uninitialized pointer later.
An out-of-bounds write flaw was found in X.Org and Xwayland. The function GetBarrierDevice() searches for the pointer device based on its device ID and returns the matching value, or supposedly NULL, if no match was found. However, the code will return the last element of the list if no matching device ID is found, which can lead to out-of-bounds memory access.
A use-after-free flaw was found in X.Org and Xwayland. When changing an alarm, the values of the change mask are evaluated one after the other, changing the trigger values as requested, and eventually, SyncInitTrigger() is called. If one of the changes triggers an error, the function will return early, not adding the new sync object, possibly causing a use-after-free when the alarm eventually triggers.
A use-after-free flaw was found in X.Org and Xwayland. The root cursor is referenced in the X server as a global variable. If a client frees the root cursor, the internal reference points to freed memory and causes a use-after-free.
A flaw was found in the X.Org server. The cursor code in both Xephyr and Xwayland uses the wrong type of private at creation. It uses the cursor bits type with the cursor as private, and when initiating the cursor, that overwrites the XSELINUX context.
A flaw was found in the X.Org server. The GLX PBuffer code does not call the XACE hook when creating the buffer, leaving it unlabeled. When the client issues another request to access that resource (as with a GetGeometry) or when it creates another resource that needs to access that buffer, such as a GC, the XSELINUX code will try to use an object that was never labeled and crash because the SID is NULL.
A flaw was found in xorg-server. A specially crafted request to RRChangeProviderProperty or RRChangeOutputProperty can trigger an integer overflow which may lead to a disclosure of sensitive information.
A flaw was found in xorg-server. Querying or changing XKB button actions such as moving from a touchpad to a mouse can result in out-of-bounds memory reads and writes. This may allow local privilege escalation or possible remote code execution in cases where X11 forwarding is involved.
In rfb/CSecurityTLS.cxx and rfb/CSecurityTLS.java in TigerVNC before 1.11.0, viewers mishandle TLS certificate exceptions. They store the certificates as authorities, meaning that the owner of a certificate could impersonate any server after a client had added an exception.
TigerVNC version prior to 1.10.1 is vulnerable to stack buffer overflow, which could be triggered from CMsgReader::readSetCursor. This vulnerability occurs due to insufficient sanitization of PixelFormat. Since remote attacker can choose offset from start of the buffer to start writing his values, exploitation of this vulnerability could potentially result into remote code execution. This attack appear to be exploitable via network connectivity.
TigerVNC version prior to 1.10.1 is vulnerable to heap buffer overflow, which could be triggered from DecodeManager::decodeRect. Vulnerability occurs due to the signdness error in processing MemOutStream. Exploitation of this vulnerability could potentially result into remote code execution. This attack appear to be exploitable via network connectivity.
TigerVNC version prior to 1.10.1 is vulnerable to heap buffer overflow, which occurs in TightDecoder::FilterGradient. Exploitation of this vulnerability could potentially result into remote code execution. This attack appear to be exploitable via network connectivity.
TigerVNC version prior to 1.10.1 is vulnerable to heap buffer overflow. Vulnerability could be triggered from CopyRectDecoder due to incorrect value checks. Exploitation of this vulnerability could potentially result into remote code execution. This attack appear to be exploitable via network connectivity.
TigerVNC version prior to 1.10.1 is vulnerable to stack use-after-return, which occurs due to incorrect usage of stack memory in ZRLEDecoder. If decoding routine would throw an exception, ZRLEDecoder may try to access stack variable, which has been already freed during the process of stack unwinding. Exploitation of this vulnerability could potentially result into remote code execution. This attack appear to be exploitable via network connectivity.
In TigerVNC (CConnection.cxx CConnection::CConnection), an unauthenticated client can cause a small memory leak in the server.
Upstream patch:
https://github.com/TigerVNC/tigervnc/pull/436/commits/dccb5f7d776e93863ae10bbff56a45c523c6eeb0
In TigerVNC (SMsgReader.cxx SMsgReader::readClientCutText), an authenticated client can crash the server by causing an integer overflow.
Upstream patch:
https://github.com/TigerVNC/tigervnc/pull/436/commits/bf3bdac082978ca32895a4b6a123016094905689
In TigerVNC (SSecurityPlain.cxx SSecurityPlain::processMsg), unauthenticated users can crash the server by sending long usernames.
Upstream patches:
https://github.com/TigerVNC/tigervnc/pull/440/commits/62197c89e98be47a174074e4c7429c57767a4929 https://github.com/TigerVNC/tigervnc/pull/440/commits/9801c5efcf8c1774d9c807ebd5d27ac7049ad993