Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel
- ID
- 19624
- Status
- summarized
- Published
- 30 Aug 2026, 4:51 PM
- Fetched
- 01 Sep 2026, 6:35 PM
- Provider
- Hacker News
- Category
- dev-community
- Original URL
- https://www.qubes-os.org/news/2026/08/29/qsb-118/
- Source URL
- https://hnrss.org/best
Summary
- Score
- 2.5
- Created
- 01 Sep 2026, 6:37 PM
- Tags
- Audience
- developers
What happened
Qubes OS Security Bulletin 118 discloses a Dom0 arbitrary code execution vulnerability in qvm-copy-to-vm's error reporting path. When dom0 copies a file to a compromised qube, that qube can send a malicious filename back in the error confirmation; the sanitize_remote_filename() function strips control characters and quotes but not shell metacharacters, and the error handler passes the result through system(), enabling command injection into dom0. Users are advised to update normally to receive the patch.
Why it matters
Unless you run Qubes OS, there is no action to take. The broader lesson is concrete: sanitizing untrusted input by allowlisting printable ASCII is insufficient if the downstream consumer is system() or any shell-invoking function—shell metacharacters like backticks, $(), ;, and | survive that filter. If you write error-handling or logging code that interpolates untrusted strings into shell calls, audit for this pattern.
Discussion angle
The classic pitfall of input sanitization that targets one attack surface (control characters) while ignoring the downstream attack surface (shell metacharacters passed to system())—worth a 2-minute cautionary tale for anyone building CLI tools that handle untrusted filenames.