LibVNCClient Flaw CVE-2026-44988: Malicious VNC Server Can Hijack Your PC On Connect

A critical CVSS 8.8 (High) vulnerability, CVE-2026-44988, has been disclosed in LibVNCClient, the open-source library that underpins much of the remote desktop software on Linux. The project published a GitHub Security Advisory (GHSA-jcc5-8wj4-7c58) on May 6, 2026, and NVD formally registered the CVE on May 27.

What sets this flaw apart from previous VNC vulnerabilities is the direction of attack. People typically picture the risk as "someone breaks into the remote desktop server," but this one runs the other way: an attacker stands up a malicious VNC server and hijacks the client PC of whoever connects to it. The victims are the people reaching out to operate someone else's machine, in other words IT administrators and maintenance engineers.

Affected downstream projects include the popular Linux remote desktop client Remmina, KDE's KRDC, the Android client AVNC, and the surveillance camera recording system ZoneMinder. The fix has already landed in master, but as of this writing (May 28, 2026), no tagged release containing it has shipped, leaving operators to rely on workarounds.

What LibVNC Is

VNC (Virtual Network Computing) is a classic mechanism for viewing and controlling another computer's screen across a network. It is used to manage servers at remote sites, to help family members by watching their PC live, or to reach work machines from home. It plays a role similar to Windows Remote Desktop or TeamViewer, but VNC is an open specification, and many free software projects ship compatible implementations.

LibVNCServer/LibVNCClient is the foundational building block for many of those implementations. It packages the VNC protocol, screen compression, and encryption into a C library that developers building VNC software can call into. LibVNCServer handles the "screen broadcasting" side, while LibVNCClient handles the "screen viewing" side.

The software the project officially tracks as users of the library includes, roughly, the following. Because this vulnerability lives in the client-side code path, the impact is limited to software that embeds LibVNCClient, i.e. the "viewer" side.

These tools are common in real-world settings: running internal corporate servers, managing research lab machines, and operating home NAS boxes or Raspberry Pi devices remotely. Remmina in particular ships as a standard package on Ubuntu, Debian and other distributions, and is often the first remote desktop tool a Linux user installs.

An Inverted Threat Model: The Connecting Side Gets Hit

Most VNC vulnerability headlines describe attacks against a VNC server that lead to compromise inside that server. CVE-2026-44988 flips that around: an attacker-controlled VNC server can rewrite memory inside any client that simply connects to it.

Plausible attack scenarios include:

• Sending a URL over social media or chat with a "come check out our demo server" pitch to get the target to connect.
• Standing up a phishing site that impersonates a legitimate VNC server, publishing a password, and luring users into connecting.
• An attacker already inside the corporate network sitting in wait for an IT administrator's remote maintenance session and redirecting it to a rogue server (man-in-the-middle).
• A malware-infected machine pretending to be "the usual VNC server" through DNS rewrites.

The "UI:R" (User Interaction Required) portion of the CVSS vector refers to that act of connecting. The attack does require the user to initiate the connection, but the chain "IT administrator opens what they think is a routine VNC session and ends up owned" fits comfortably into normal day-to-day operations.

Inside CVE-2026-44988: A 2048-Pixel Fixed Buffer in the Tight Decoder

The root cause lives in LibVNCClient's src/libvncclient/tight.c. NVD classifies it as CWE-787 (Out-of-bounds Write). The bug is in the code that handles Tight encoding, one of VNC's screen compression modes.

Tight encoding, originally developed by the TightVNC team, breaks each screen block into subencodings such as "solid fill," "JPEG image," and "gradient" (smooth color transitions) for compression. The flaw is in the gradient subencoding path. LibVNCClient used a fixed-size buffer sized for a 2048-pixel-wide row to do this work.

A VNC server can announce to the client, "I'm about to send you an image 3000 pixels wide." LibVNCClient trusted the announced width rw and executed writes like memset(client->tightPrevRow, 0, rw * 3) against its internal fixed 2048-pixel buffer. Whenever rw exceeds 2048, the write spills past the boundary of the allocated region.

Sitting just beyond that boundary are the callback function pointers (the "addresses" the program will jump to next) inside LibVNCClient's rfbClient structure. If an attacker can overwrite those pointers with the address of code they control, subsequent processing inside LibVNCClient ends up executing the attacker's code. The GitHub advisory notes that "constrained read/write primitives have been demonstrated in a lab environment, with RCE-class impact considered plausible."

The fix landed in commit 5b27054: it introduces a new macro constant TIGHT_GRADIENT_MAX_WIDTH and bails out of processing as soon as a width over 2048 is received. It is a simple gatekeeping check at the entry point.

No Tagged Release With The Fix Yet (as of May 28, 2026)

The hardest part of CVE-2026-44988 is that the fix is in master, but no tagged release containing it has been published. On the LibVNCServer releases page, the current latest version remains v0.9.15, with no tag cut that includes the fix commit.

In practical terms, that means the Remmina and KRDC packages shipped by Ubuntu, Debian, Arch Linux and similar distributions will, for some time, continue to embed a vulnerable LibVNCClient. Either each distribution's security team applies its own patch and ships an updated package, or the world waits for upstream to tag a new release.

The same goes for Remmina on Windows/macOS and AVNC on Android: users will continue running vulnerable binaries until each project pulls in the newer LibVNCClient and rebuilds. VNC-related features bundled in container images and consumer NAS appliances (Synology, QNAP, etc.) may also have to wait on vendor updates.

What To Do Now

Until a fixed release reaches you, the following workarounds are worth applying operationally.

1. Avoid connecting to untrusted VNC servers. Restrict business VNC connections to servers you operate yourself or vetted servers belonging to contracted partners. For the time being, do not open VNC URLs handed to you via social media or chat with a casual "could you take a look at this?" framing.

2. Limit the network path (VPN/SSH tunnels). VNC has long been known as a protocol with weak authentication and encryption. The right posture is to avoid exposing raw VNC over the internet altogether and instead tunnel it through a VPN or SSH port forwarding. Doing so also significantly reduces the risk of being redirected to a rogue server by a man-in-the-middle.

3. Check distribution security updates daily. On Ubuntu/Debian-based systems, a simple check such as apt list --upgradable | grep -E "vnc|remmina|krdc" is enough to surface relevant package updates. Track the security advisories of each distribution (USN, DSA, and so on) and watch for LibVNC-related announcements as a priority.

4. Revisit remote maintenance procedures. Now that "just connecting to the usual VNC server" is itself an attack surface, operational rules carry real weight: require two-step confirmation before connecting to unknown servers, verify fingerprints on first connection, and so on. This is also a good moment to check whether your internal IT maintenance VNC servers are reachable from outside the network at all.

5. Inventory your own products that embed LibVNCClient. If your product uses LibVNCClient internally (for a remote support tool, an embedded device's remote screen feature, etc.), you will need to decide whether to build and ship a fork that includes the fix commit, or wait for the official release before pushing an update to customers.

Why VNC Keeps Producing These Flaws

VNC is an old protocol, developed at the AT&T Laboratories in 1998 and originally designed for use inside corporate LANs. The protocol spec lacks strong authentication and encryption, and the image compression code base it depends on is long-lived C code.

There is precedent: in 2019, Kaspersky ICS CERT disclosed 37 CVEs across four products: LibVNCServer, LibVNCClient, TightVNC, TurboVNC, and UltraVNC. The common thread is a classic case of trusting the length and size fields in screen update packets too readily, and CVE-2026-44988 lives in the same lineage.

Attackers care about VNC as a foothold into enterprise environments and IT administrator workstations. The CISA KEV dashboard already records multiple past VNC-related CVEs that ransomware groups have leveraged, and CVE-2026-44988 has a real chance of joining the list of observed-in-the-wild bugs within the next few months.

Keeping up with these "unpatched CVEs in your OSS dependencies" requires the ability to scan your own library tree end to end. Our OSS Supply Chain Scanner lets you check the latest CVE status of OSS packages including LibVNC in one place. For vulnerabilities like this one, where a tagged release is slow to materialize, identifying your exposure early is what makes operational decisions possible.

References

• ▸ NVD - CVE-2026-44988 Detail (registered May 27, 2026)
• ▸ GitHub Security Advisory - GHSA-jcc5-8wj4-7c58 (published May 6, 2026)
• ▸ GitHub commit 5b27054 - libvncclient: fix Tight gradient decoding overflow
• ▸ LibVNCServer/LibVNCClient official site (includes downstream project list)
• ▸ GitHub - LibVNC/libvncserver Releases
• ▸ Kaspersky ICS CERT - VNC vulnerability research (37 prior VNC-related CVEs)
• ▸ Remmina official site
• ▸ CISA - Known Exploited Vulnerabilities Catalog