Yaamlabs
Vulnerabilities

X.Org fixes 12 flaws in the X server and Xwayland

xorg-server 21.1.25 and xwayland 24.1.14 fix 12 memory bugs, nine of which can lead to code execution. Who is exposed, how to check, and what to patch first.

By Yaali. October 12, 2026, 6 min read, Vulnerabilities, Patching.

Cover illustration of a desktop monitor with overlapping windows, linked by glowing cables to a distant server rack, with glass shards breaking off one window, with the Yaamlabs logo and the text: X.Org patches 12 flaws in X server and Xwayland, 9 of 12 can lead to code execution

On October 7, 2026, X.Org published a security advisory for 12 memory safety bugs in the X server and in Xwayland, the X server that lets older X11 applications run on a Wayland desktop. The fixes are in xorg-server 21.1.25 and xwayland 24.1.14. The advisory says nine can lead to arbitrary code execution; the other three can crash the server or leak heap memory. Eleven affect both servers, and one (CVE-2026-93522) affects only Xwayland.

The advisory says ten of the twelve need an authenticated X client, meaning a program already connected to the display, to send crafted requests; the two memory leak entries state no precondition. That makes these local bugs, and Red Hat's preliminary scores sit at 7.8 for most of the code execution flaws. They matter most where Xorg still runs as root, on multi-user remote desktop servers, and on workstations that accept X11 forwarded over SSH from less trusted hosts. No exploitation has been reported, and all twelve were reported through the TrendAI Zero Day Initiative.

Table of the 12 CVEs fixed in xorg-server 21.1.25 and xwayland 24.1.14, with the X extension each sits in, the bug, the worst case named by X.Org and Red Hat's draft CVSS score

How the bugs work

An X server draws windows and handles input for every connected client. Its extensions (XKB for keyboard maps, GLX for OpenGL, RandR for screens, XInput for input devices) each parse their own requests. Any client that gets past the display's access check, normally by holding the session's MIT-MAGIC-COOKIE from ~/.Xauthority, can send any of these requests. All twelve bugs are in that parsing code.

The overflows come from size checks that do not match the copy that follows them:

  • CVE-2026-93517 (GLX). RenderLarge allocates a buffer of cmdlen bytes, then copies dataBytes into it without checking that the second is no bigger than the first.
  • CVE-2026-93518 (XKB). XkbResizeKeyType() stores (nTotal * 15) / 10 in an unsigned short. Large values wrap past 65,535, the allocation comes out too small and later writes run off the end.
  • CVE-2026-93519 (XFIXES). input_constrain_cursor() writes barrier events into a fixed-size buffer without a bounds check. A client that creates more than 100 pointer barriers and then moves the pointer through XTEST overflows it. Both extensions are on by default.
  • CVE-2026-93521 (RandR). Prepending data to a provider property sizes the new buffer from the wrong length. The same bug was fixed earlier for output properties but never copied over to providers.
  • CVE-2026-93520 (XKB) is what is left of an earlier, incomplete fix: the names array is still sized from max_key_code + 1, while the code that clears it uses a larger length.

The other four code execution bugs are mixed. CVE-2026-88812 frees an XKB text doodad on an error path and frees it again during cleanup. CVE-2026-93516 lets a passive grab keep a raw pointer to an input device after the client removes that master device. CVE-2026-93523 skips the modifier range check in the XInput2 passive ungrab path, so an out-of-range modifier becomes an array index. CVE-2026-93522 sizes a Glamor (GPU acceleration) copy buffer from the destination height but indexes it with source coordinates.

Code execution here runs with the X server's privileges: root if Xorg runs as root. If it runs as the logged-in user, which is the default on most current distributions with open-source drivers, the attacker gets that user's session. The X11 protocol already lets a connected client read keystrokes and screen contents from other clients, so on a single-user desktop where every client is the user's own program, these bugs add little. They matter where the client is less trusted than the server.

Who is realistically exposed

SSH X11 forwarding. With ssh -X or ssh -Y, programs on the remote host connect back to the X server on your workstation. If that remote host is compromised, a forwarded program can send these requests to your display. -Y gives the remote client full trusted access. -X marks it untrusted through the X SECURITY extension when ForwardX11Trusted no is set, but Debian's OpenSSH client defaults to ForwardX11Trusted yes as a Debian-specific change, which makes -X behave like -Y. ssh -G <host> | grep -i forwardx11trusted shows the value your client will use. The advisory does not say which of the twelve the SECURITY extension would block, so treat untrusted mode as a reduction in risk.

Root-run Xorg. Older setups, some proprietary drivers and display managers configured with needs_root_rights = yes in /etc/X11/Xwrapper.config still start Xorg as root. Any user who can connect a client to that display can then try to turn one of these bugs into root.

Shared and multi-user hosts. Remote desktop servers built on Xvnc (TigerVNC) or xrdp, university and lab machines, and jump hosts with graphical tools carry the same code. Red Hat lists its tigervnc package as affected on RHEL 7, 8 and 9 alongside xorg-x11-server and Xwayland.

Xwayland desktops. On GNOME and KDE Plasma under Wayland, Xwayland serves X11 applications and runs as the logged-in user. Debian rates the Xwayland fixes as unimportant on that basis, with the note that Xwayland should not run as root.

What to do

Four steps: find which X servers run and as which user, patch root-run and shared hosts first, limit who can connect to the display until patched, and look for X server crashes

1. Find the X servers and their version

Xorg -version and Xwayland -version print the server version. Distribution packages keep their old version number when they backport fixes, so check the package against your distribution's advisory: dpkg -l xserver-xorg-core xwayland on Debian and Ubuntu, rpm -q xorg-x11-server-Xorg xorg-x11-server-Xwayland tigervnc-server on RHEL and Fedora. To see which user each server runs as, use ps -o user=,args= -C Xorg,Xwayland,Xvnc.

2. Patch, starting with the risky hosts

Upstream fixes are xorg-server 21.1.25 and xwayland 24.1.14; X.Org also released 26.0.99.903 release candidates of both on the same day. When we checked Debian's tracker on October 12, only unstable had fixed packages (xorg-server 2:21.1.25-1, xwayland 2:24.1.14-1), with bookworm, trixie and forky still listed as vulnerable. Red Hat lists packages in RHEL 7 to 10 as affected, with no errata yet.

Patch root-run Xorg first, then multi-user hosts, then single-user desktops. The updated package does nothing until the X server restarts, which means logging out and back in, or restarting the display manager or the Xvnc session.

3. Until packages arrive

  • Forward X11 only from hosts you trust, and set ForwardX11Trusted no in ~/.ssh/config or /etc/ssh/ssh_config so -X really is untrusted.
  • Set X11Forwarding no in /etc/ssh/sshd_config on servers where nobody needs graphical tools.
  • Run xhost with no arguments. If it reports that access control is disabled, turn it back on with xhost -, and remove entries you did not add with xhost -<name>.
  • Make sure no X server listens on TCP port 6000 (ss -ltn 'sport = :6000'). Current Xorg defaults to -nolisten tcp; keep it that way.
  • Where a root-run Xorg is not needed, set needs_root_rights = auto or no in Xwrapper.config and confirm the session still starts.

4. Check for signs of attempts

Failed heap exploitation attempts usually crash the server and end the session. coredumpctl list Xorg and coredumpctl list Xwayland show recorded crashes. The X server log (/var/log/Xorg.0.log, or ~/.local/share/xorg/Xorg.0.log for rootless Xorg) ends with a backtrace after a crash. An X server crash right after a forwarded or remote session connected deserves a closer look at the remote host that client came from.

Old code, broad reach

This is the second X server security release in three months, after 21.1.24 in July, and two of this month's bugs are incomplete or unported earlier fixes. X11 is meant to be on its way out, yet it stays on fleets through Xwayland, VNC servers and SSH habits, so track it in the patch inventory like any other service.

If you want to know where X servers, SSH forwarding and root-run display services sit across your estate, our safeguarding and hardening work covers that, and on-demand risk reduction can help close the gaps. Open the chat and Yaali, our AI agent, will pass your question to an engineer.


Sources: X.Org security advisory, October 7, 2026, xorg-announce archive, October 2026, Help Net Security, Debian security tracker, CVE-2026-93517, Debian security tracker, CVE-2026-88812, Red Hat, CVE-2026-93517, Red Hat, CVE-2026-88812, Phoronix, FreeBSD VuXML, xorg-server 21.1.24.

Read next

Back to the blog, or tell us about your system in the chat. Yaali, our AI agent, answers first and brings in an engineer.