X.org Security Advisory: multiple security issues X.Org X server and Xwayland
58 comments
·November 2, 2025dingdingdang
richard_todd
On their github you can see all three changes identical to x.org's happened on October 28th (same day as the advisory). So, they were not already fixed, but the fixes were applied immediately.
kevin_thibedeau
Coverity is pretty good about finding these kinds of bugs. Is there a reason why a project as significant as Xorg isn't taking advantage of their gratis access for that tool?
josteink
I think the short story is that the people who develop Wayland are the people who used to develop Xorg.
And they’d rather spend their energy on giving you a compelling reason to switch, rather than using it to add to the reasons for staying on a project they now consider obsolete.
You may disagree with their assessment, but you can’t blame them for how they decide to prioritize.
rwmj
Good that people are finding and fixing these, but basically allowing any untrusted client to talk to your X server is asking for trouble just by design. (Bonus points if you have any Tcl/Tk apps running, where you can simply transmit commands for the program to run via the X server.)
jeroenhd
There are plenty of setups where the X server runs at higher privileges/on a different host than the (partially trusted) application that might exploit the X server. This is a classic elevation of privileges vulnerability in those setups.
X11's practical absence of any security mechanisms for user sessions means you should probably not run any kind of low-trust UI program anyway, as there is no prevention of keystroke injection or screen recording, but that's a design flaw that will never be solved. That doesn't mean that EoP style attacks like these should be ignored or underestimated, though.
0xbadcafebee
Why do people keep persisting this myth? X11 has authentication. You can either rely on filesystem permissions, or a shared secret. The same way thousands of other network servers work.
Any program you run on a computer (especially a Linux computer, which lacks modern OS security measures and has constant privesc kernel holes) exposes you to security flaws. There has yet to be any computer system designed that a hacker can't break out of. If you intentionally download and execute a program, you are rolling the dice, regardless of what the software is.
What's insane about all these discussions is that NOBODY IS HACKING X SERVERS. There's a thousand other kinds of software on Linux that there is real malware for. But nobody is trying to hijack your X11 session. This imagined threat is a red herring designed to bolster the argument for Wayland's horrible designs.
zdragnar
> What's insane about all these discussions is that NOBODY IS HACKING X SERVERS
I knew someone who worked for a small loan type company. Passwords were stored in plain text, but even worse, the login form didn't actually check the password at all, it created valid sessions as long as you provided a valid user name.
When he informed his boss that was very bad, his boss simply said that nobody has abused it, and nobody would, don't waste time changing it.
The point, of course, is why would you wait until people are getting hacked to address a known vulnerability?
Sure, there are others, and they should be closed too, and they are when they are found. It makes no sense whatsoever to leave one open just because.
tapoxi
I think the issue isn't that you downloaded random hostile software, but that other software you do use has some sort of vulnerability (recent Unity vulnerability, browser sandbox escape, etc) and an issue like this would allow for privilege escalation.
Wayland doesn't need X11's vulnerability as its only argument, Wayland is a much simpler design that is easier to iterate on because it doesn't assume the client and server are on different machines. The fact that it moves privileged APIs like screen capture behind portals is a bonus.
jchw
> Why do people keep persisting this myth? X11 has authentication. You can either rely on filesystem permissions, or a shared secret. The same way thousands of other network servers work.
Any program you incidentally run within a typical graphical user session will have access to the X socket and a cookie, they will be able to connect. And after they connect... They basically just can do anything they want with zero real restrictions, including most likely some fairly trivial paths to root escalation. Even if they're running inside of a sandbox or container, with only an X11 socket poking through.
This problem was realized a very long time ago with the security extension but most of it never really caught on.
> Any program you run on a computer (especially a Linux computer, which lacks modern OS security measures and has constant privesc kernel holes) exposes you to security flaws. There has yet to be any computer system designed that a hacker can't break out of. If you intentionally download and execute a program, you are rolling the dice, regardless of what the software is.
If you believe this is true, then what exactly is the point of any security measure? Why bother using isolation and sandboxing, or passwords? Why does Windows bother patching flaws if they know there are certainly more of them and they will never fix them?
Do you by chance also smoke because you're going to die anyways?
> What's insane about all these discussions is that NOBODY IS HACKING X SERVERS. There's a thousand other kinds of software on Linux that there is real malware for. But nobody is trying to hijack your X11 session. This imagined threat is a red herring designed to bolster the argument for Wayland's horrible designs.
Lol. That's primarily because the Linux desktop is utterly irrelevant, not because nobody would care to do it. Is it really surprising that attacks against desktop computers would focus almost entirely on the OS that has 90+% of the market share? We don't get free software OS desktop malware for the same reason we don't get free software OS software ports.
Watching and waiting with security was a totally acceptable position in the 90s, but we get the general gist these days. We need security-by-design.
On the server side of Linux where Linux is relevant, the situation is much more impressive; auditing using eBPF, sandboxing with gVisor, microVMs with Firecracker and cloud-hypervisor, isolation using namespaces and seccomp-bpf and more.
On the desktop side, people are still arguing over whether or not it's a problem that any X client can by default silently keylog the entire system trivially. Okay, but a lot of us actually see that as a problem, and we're not interested much in "hearing you out". Most of us recognize that the Wayland protocol has warts (and too many damn protocols), but X11 has many more warts. I didn't care what was the successor to X11 specifically, I just cared that we eventually made some progress. Most people have nothing to offer here and just suggest we should've stuck with X11. Okay dude, but nobody wants to. The X.org devs would like to move on. The desktop environments really would like to move on. There was basically one serious guy that actually wanted to work on improving X11 and he turned out to be kind of crazy and couldn't stop breaking shit anyways.
uecker
X11 had the distinction between trusted and untrusted X11 clients basically forever. But nobody bothered to even spend the minimal amount of work to make this usable in practice^1. This had two reasons: 1.) It is irrelevant when you run the programs as the same user so nobody bothered (and no: Wayland does not help: https://github.com/Aishou/wayland-keylogger) 2.) It is more fun to simply pretend it is unfixable broken and write something new (something any good engineering manager should have stopped immediately).
¹. I used to use this and also fixed some bugs in some programs. The main problem when I last checked a decade ag was that some important extensions such as composite would need to be exposed to untrusted clients.
Jasper_
That Wayland keylogger is not the same thing. X11 has several mechanisms (XTest, XRecord, XI raw inputs) to receive a global raw key input stream, accessible to anyone who connects to the X server, without even making a visible window surface. It even bypasses grabs, meaning that your lock screen password entry can be snooped on.
The Wayland keylogger acts like an application; all Wayland compositors will only send key events to the focused surface, so the user has to focus an active surface in order to get key events. Even in the scenario where you've LD_PRELOAD-hooked all applications, you still will never get the lock screen password, as the compositor never sends it out across the wire.
LD_PRELOAD is problematic from a security perspective, but it's not Wayland-specific: the same issue is true for CLI applications and X11 applications, and any attacker with the ability to write files could also just replace your binaries with malicious ones (stuff them somewhere into ~/.hidden, and then add a $PATH entry to the start).
rich66man
> something any good engineering manager should have stopped immediately
Who exactly should and can control the horde of OSS developers?
mikkupikku
I don't think I've seen X configured to run as root in probably 15 years. If anybody still does anything like that, they're literally asking for it.
_flux
Hmm.. On my Debian ps axuw|grep Xorg says
root 34595 2.7 0.4 26146280 532248 tty4 Sl+ Nov13 783:33 /usr/lib/xorg/Xorg vt4 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -nolisten tcp -background none -noreset -keeptty -novtswitch -verbose 3mrktf
Digging deeper there are mechanisms for long time on internal X side (see https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/Xserv... ) - granted never seen it practically implemented.
And going to rabbit hole there are even proof of concept security implementation named Xnamespace for Xorg fork (needs polishing and much more patches but looks doable. see wip documentation: https://raw.githubusercontent.com/X11Libre/xserver/d2b60a3d6... )
lotharcable
The way X11 developers ended up fixing this is by creating Wayland. This way privileged operations (like keylogging, screen capture, etc) require the cooperation and authentication through the display server.
udev4096
Any application can literally log EVERYTHING! It's good to see wayland getting better everyday
null
exasperaited
> Bonus points if you have any Tcl/Tk apps running, where you can simply transmit commands for the program to run via the X server.
Back in 1996 the level of X integration in Tk was awesome; I had a shell tool that could make Netscape do stuff by firing MIT magic cookies at it.
In a contemporary setting, it's pretty horrifying.
samtheprogram
Would Fil-C have prevented the first or third?
DonHopkins
[flagged]
lotharcable
[flagged]
jlokier
One of the use-cases of Fil-C is to prevent security issues in old C code that's much older than Fil-C itself.
embedding-shape
> Probably not seeing how the code for at least the 3rd was written in 1994, some 30 years before Fil-C existed.
How is this possibly the most charitable reading of parents comment, and honestly, do you think that's what they meant? You can't read that in some other way, where maybe parent wasn't actually asking about time traveling but something else?
lotharcable
Yes it was bit uncharitable, but I couldn't resist based on the way he phrased it. It was just a joke.
"Preventing" the vulnerability would indeed require going back to 1994. Since it is a vulnerability that has existed in every display server released since then.
TacticalCoder
[dead]
Wonder how these play out against the https://github.com/X11Libre/xserver base, would be interesting to hear from that end as to how these things are handled. My understanding is that they address any sec issues that arise on x.org but it would be fascinating if the issues are already mitigated since XLibre updated their xserver port with 1000s of issues that were never addressed on the x.org side of things.