Rhe X.Org Foundation released emergency updates closing eight memory-safety vulnerabilities in xorg-server (21.1.26) and XWayland (24.1.15). Seven flaws affect both codebases, while the eighth, an out-of-bounds EDID write, bites only the full X.Org Server. Most bugs are integer overflows and length-check bypasses that could crash the display server or enable local privilege escalation, and they were found largely with AI/LLM assistance. Users should update to at least these versions, ideally verifying the package before rebuilding from source.

X.Org Foundation issues emergency security patch for eight flaws in X server and XWayland

The fixes, found largely with AI help, close out-of-bounds writes and integer overflows that could let a local client escalate privileges.

Today, the X.Org Foundation pushed emergency updates to its two flagship display servers. The release closes eight memory-safety vulnerabilities in a single advisory, bumping xorg-server to 21.1.26 and XWayland to 24.1.15. Both projects should be updated. Anything older is vulnerable.

Seven of the eight flaws hit both codebases. The eighth, an out-of-bounds write while parsing an EDID blob from a physical monitor, only affects the full X.Org Server. Unpatched, some of these crash the display server outright. Others can let an authenticated local client reach memory it otherwise shouldn't, which is the classic recipe for local privilege escalation.

The most interesting part isn't the bugs themselves. It's where they came from. The flaws were found "with the assistance of AI/LLMs." That phrasing is now routine. LLM-assisted auditing has turned into a dominant source of X.Org security findings throughout 2026, and this batch simply adds to the tally.

The fixes were authored largely by Olivier Fourdan of Red Hat. Alan Coopersmith of Oracle contributed patches too, as did independent researchers Eun0us of Espilon and Acts1631, with external reporter Tristan Madani of Talence Security rounding out the list.

Eight flaws, one ancient family

The specific IDs aren't the story, but they help trace accountability.

Acts1631 reported three: a shared-memory bounds overflow in the XvShmPutImage path (CVE-2026-109092), a stack out-of-bounds write in XTest input simulation (CVE-2026-109093), and a request-size overflow in XRes (CVE-2026-109904). On the XRes one, a large count wraps to a small value on a 32-bit server, so a too-short request passes length validation and the handler reads past the end of the buffer. That exposure is essentially a 32-bit-only problem.

Tristan Madani found three more: CVE-2026-109095, CVE-2026-109096, and CVE-2026-109903, all sitting in the Xv and glamor image-handling code. They share a common theme. A driver-supplied image size that's negative or computed with 32-bit integers makes length checks pass for requests that don't actually carry their claimed payload. The server then processes data that isn't there.

There's a fourth XRes overflow too, in the byte-swapped variant of the same extension (CVE-2026-109094). It isn't individually credited, which points to a self-discovery during the same review batch. Another 32-bit integer wraparound, so the exposure stays narrow.

The EDID flaw, found by Eun0us of Espilon, is the odd one out (CVE-2026-109091). X.Org records Display-Range descriptors into fixed-size arrays during display init, without checking the count. A misbehaving monitor or a crafted EDID blob can push extra descriptors past those arrays and clobber adjacent fields. XWayland never reads EDID from a physical display directly, so it dodges this path entirely.

You might notice two identifiers look like a transposition of adjacent numbers: CVE-2026-109904 and CVE-2026-109903. They're real, though. Those are the officially assigned IDs as published by the Foundation, appearing consistently across the announcements and the advisory.

Keeping forty-year-old code alive

This release is the newest in a long series. The last twelve months read like a calendar of security advisories. April shipped five flaws including an XKB integer underflow. June delivered nine AI-discovered bugs, this time sourced from ZDI. July and August brought glamor font-atlas issues and font-server overflows. October alone delivered two batches, one claiming nine of twelve flaws could lead to code execution.

The bugs are recognizably the same family, though. Integer overflows, unchecked length validation, buffer overflows in request handlers. This has plagued X.Org since at least 2017. The codebase is roughly forty years old. AI isn't inventing new categories of mistakes here. It's just reading old C faster than any human audit could.

A small team keeps it all standing. A handful of maintainers effectively manage the releases, even as the wider ecosystem shifts to Wayland. Red Hat is quietly moving on. The company plans to remove the standalone X.Org Server from RHEL 10, keeping only XWayland for legacy app compatibility.

The full X.Org Server has been in maintenance mode since roughly 2019. It still gets critical security fixes, carried largely on the efforts of Olivier Fourdan and his colleagues. It's a rather lean operation for software this central to Linux desktops, though the transition to Wayland is meant to eventually remove the need for it.

So what should you actually do?

Install xorg-server 21.1.26 or newer and XWayland 24.1.15 or newer through your distribution's package manager. Most major distros ship point releases, so this is likely already waiting in your repos. Keep in mind that most of these need a local, authenticated X client to exploit. In practice that means another user account on the same box, or, for the EDID flaw, a plugged-in display. This isn't a remote attack for the typical desktop, so the blast radius is smaller than the "privilege escalation" label implies.

Verify the version if you're unsure. Run Xorg --version on a running system, and query the XWayland package with your package manager's standard command.

There's no rush to abandon X11 either. Native Wayland apps sidestep the X layer entirely, but legacy X11 applications still run fine through a patched XWayland. If local access to your display server matters, limiting who can connect, xhost controls and unprivileged sessions, buys you some room before patches land.