Arbitrary code execution breaking sandboxes in KDE Plasma | Kimiblock's Blog
Articles<br>78<br>Tags<br>107<br>Categories<br>22
Posts Archives<br>Categories<br>Tags<br>In memory of our puppet
Go About<br>Terms<br>Kraftland<br>Warp...<br>Today
Arbitrary code execution breaking sandboxes in KDE Plasma<br>Created2026-07-01|Updated2026-07-02
PoC<br>This proof of concept demonstrates a mean for malicious sandboxed (Flatpak here, but any sandbox apply. With or without the security context support.) applications to impersonate and, more importantly, spawn arbitrary binaries on the host when user invokes Open New Window action.
This demonstration utilises Arch Linux host with some dependencies (wget, unzip, meson) to build the malicious binary, and a Flatpak application io.github.johannesboehler2.BmiCalculator with no granted permission (except for the evil binary we have to pass in, because building things inside Flatpak is not easy).
You will need kcalc (/usr/bin/kcalc) as the designated target.
Build the evil binary on host:
cd /tmp<br>wget https://github.com/Kimiblock/mesa-demos-argv0/archive/refs/heads/argv0.zip<br>unzip argv0.zip<br>cd mesa-demos-argv0-argv0<br>meson setup build<br>meson compile -C build/
Install the Flatpak app and provide said binary to it.
flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo<br>flatpak install -y io.github.johannesboehler2.BmiCalculator --user<br>flatpak override io.github.johannesboehler2.BmiCalculator --filesystem=/tmp/mesa-demos-argv0-argv0/build/src/egl/opengl/eglgears_wayland
Now that it’s all set, let’s run the evil binary:
flatpak run --command=/tmp/mesa-demos-argv0-argv0/build/src/egl/opengl/eglgears_wayland io.github.johannesboehler2.BmiCalculator
Notice that in the task bar, KCalc‘s icon is being shown. If we right click and select Open New Window, the designated binary /usr/bin/kcalc starts unsandboxed, in the app.slice cgroup, using the host mount namespace, fully exposed.
Discovery<br>While testing the Portable sandbox on KDE Plasma (in a QEMU virtual machine), we just casually found out some of the windows does not have proper .desktop file associated, leaving them show up in task bar with generic “Wayland” icons. That was reported in KWin trusts on Apps fully for app_id, allowing apps to impersonate as others.
Something hits the fan<br>Since then, we had no indication on how things work on this specific desktop environment. So I decided to conduct another experiment. This time a new anomaly popped up: While accidently middle clicking on the task bar (it would invoke “Open New Window” by default for a specific app), the app launched a new window as expected, yet it did not seem to remember my saved login credentials, nor did it use any of modified settings. Upon closer inspection, combining the PID obtained from KWin Debug Console and control groups + rootfs info from procfs, a complete sandbox escape has surfaced.
Explaination<br>So it was clear, there is a complete sandbox escape when I accidently triggered a middle-click inside the virtual machine.
What’s it doing?<br>Based on the fact that KWin could not associate the window to a real .desktop file, there must be something that still allows it to find a argv0 to execute. I took a guess on /proc/PID/cmdline and it proved to be right. See the demo below.
It’s a dumpster fire<br>This is not limited to spawning existing application instances outside of the sandbox. Since it just so happens that any process, including unprivileged ones can change it’s argv0 (Note that mount namespace is also a valid choice, but less flexible.). Combined with the lack of guard on app_id, the insecure nature of reading /proc/PID/cmdline, creates a powerful exploit that allows arbitrary code execution on the host.
Demo time<br>This demo is written by GalaxySnail since I had little knowledge in C. We will be using Mesa’s eglgears-wayland as a demo.
Clone the repository: git clone https://github.com/Kimiblock/mesa-demos-argv0.git --depth=1
Change working directory: cd mesa-demos-argv0/
Edit the designated command within the main function at src/egl/opengl/eglgears.c to your liking (bash scripts, compiled binaries, you name it)
Build: meson setup build && meson compile -C build
Execute the payload: ./build/src/egl/opengl/eglgears_wayland
Open New Window (either middle-click on the icon, or select it in the context menu)
Our designated evil binary starts up
Cool, now what?<br>A real attack will probably generate a shell script under their $HOME, of which typically resides on the host with the same path. The evil app can change it’s argv0 to point at binaries generated or downloaded silently, and have total control of the session when the user clicks Open New Window, or just middle-clicks the application icon by mistake. This demonstrates a powerful attack, yet we did not receive any updates from the KDE Security email.
If KDE Plasma wants to plug this exploit in any capacity, then it should first get the applications’ ID from either the sandbox via...