Qubes OS fixes Dom0 command injection flaw in qvm-copy-to-vm error dialogs

Dom0 code execution disclosed in QSB 118

The Qubes OS project has published Security Bulletin 118, disclosing a vulnerability that lets a compromised qube execute commands of its choosing inside dom0, the privileged management domain at the core of the operating system. The flaw is reached through qvm-copy-to-vm, the utility for copying a file out of dom0 into a virtual machine, and the bulletin states that every Qubes OS release is affected. Dated 28 August 2026 and signed by Qubes developers Marek Marczykowski-Górecki and Simon Gaiser, the announcement also circulated via the Hacker News front page.

How an error dialog becomes an attack path

qvm-copy-to-vm moves data using a protocol the project calls qfile, a deliberately minimal archive format. When a transfer ends, the receiving qube sends a confirmation back to dom0 containing a checksum of the copied files, an error code, and the name of the last file received. If the copy failed, dom0 displays a GUI message combining the error information with that filename — and the filename originates from the destination qube, making it attacker-controlled whenever that qube has been compromised.

According to the bulletin, the failure has two parts. First, the incoming name passes through a sanitising function, sanitize_remote_filename(), which rewrites control characters, bytes outside printable ASCII, and double quotation marks into underscores. Shell metacharacters survive the filter. Second, the dom0 file-copy agent formats the message into a kdialog or zenity command line, depending on which dialog tool is installed, and hands the assembled string to system(), which runs it through a shell. Since the sanitiser was never designed with shell syntax in mind, the remote qube can embed commands in the filename it reports and have them executed in dom0.

The consequences are significant: an attacker who already controls a qube and gets the user to copy a file from dom0 into that qube achieves command execution in dom0 — and because dom0 administers every VM on the machine, that amounts to control of the entire Qubes installation.

The VM-to-VM path is not affected. Its error-reporting code invokes zenity or kdialog directly with an argument list, via the exec family of calls, so no shell ever sees the attacker-controlled string.

A routine update closes the hole

The fix ships in the qubes-core-dom0-linux package, version 4.3.22, for Qubes 4.3. Following the project's usual practice, the package begins in the security-testing repository and moves to the stable repository after a short community testing period. Users are told to keep updating normally through the Qubes Update tool or its command-line equivalents; no separate action is needed. Discovery of the vulnerability is credited to Tim C., and the bulletin carries PGP signatures so readers can verify its authenticity.

Why it matters

Dom0 is the trust anchor of Qubes' compartmentalisation model. The system's core promise is that even a fully compromised qube stays contained, so a path from a hijacked VM into dom0 — triggered by something as ordinary as copying a file into it — strikes precisely at the boundary the architecture is meant to defend.

The bug is also a textbook pairing of two recurring mistakes: blocklist sanitisation, where developers strip characters they consider dangerous instead of permitting only known-safe ones, and building shell commands through system() rather than calling exec-style functions with a fixed argument array. The contrast with the unaffected VM variant, which takes the second approach, shows how much the choice of API can matter.

For users, the practical step is simple: install the update. The attack requires both an already-compromised qube and user interaction, which limits exposure, but on a distribution whose purpose is containing exactly that scenario, closing the channel is essential.