Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel
vntok
217 points
89 comments
August 30, 2026
Related Discussions
Found 5 related stories in 62.2ms across 4,990 title embeddings via pgvector HNSW
- Qubes OS Security in the Public Record sciences44 · 86 pts · July 18, 2026 · 56% similar
- AI Meets Cryptography 2: What AI Found in OpenVM's ZkVM duha · 90 pts · July 17, 2026 · 50% similar
- VMs won't contain cyber-capable agents polyrand · 156 pts · August 26, 2026 · 46% similar
- ProgramBench Vetted: Reverse Engineering from a Runnable Binary rigelbm · 13 pts · August 20, 2026 · 45% similar
- Show HN: Clawk – Give coding agents a disposable Linux VM, not your laptop celrenheit · 187 pts · July 13, 2026 · 45% similar
Discussion Highlights (20 comments)
charcircuit
Another example for why system() is so dangerous to use. I also don't understand why it needs to show the dialog in dom0. If you have the option to handle attacker controlled input on the unprivileged side, you should do that instead of putting a lot of logic on the privileged side.
polotics
I'm still very impressed by qubes, and glad I'm not such a target that I feel I need the level of opsec it affords (on all my laptops). Maybe someday AI-assisted killchains will be so widespread that Qubes is the minimal level for the (few?) still-local users of compute. I would not have copied anything from dom0 to any another qube, the impact is low.
zby
I am still impressed by QubesOS track and I use it for my dedicated 'financials' laptop. IMHO the thing that is holding back QubesOS is the lack of hardware acceleration for graphics - maybe now when dual monitor setups are getting popular this could be a workaround for the security considerations?
msm_
Wow, this is serious. Makes you think, that even though QubesOS attack surface is so tiny (well-designed to be secure) there are still vulnerabilities to be found. Worth noting that (as I understand) this vulnerability occurs only when doing copy-to-VM from Dom0: >Note that the VM variant of `qvm-copy-to-vm` is not affected, as its version of the error reporting function does not use `system()`: Since you should not use Dom0 for regular work, and definitely not for interacting with likely-to-be-infected VMs, the scope of this attack is smaller than it sounds. On the flip side, when it works, it elevates privileges straight to Dom0.
TacticalCoder
I do really like the following in the bulletin: > Important: At this point, you still don’t know whether the key you just imported is the genuine QMSK or a forgery. In order for this entire procedure to provide meaningful security benefits, you must authenticate the QMSK out-of-band. Do not skip this step! The standard method is to obtain the QMSK fingerprint from multiple independent sources in several different ways and check to see whether they match the key you just imported. For more information, see How to import and authenticate the Qubes Master Signing Key. It looks like Qubes is ran by people who take security seriously, which is refreshing.
sdcfgy
Reminds me of Theo DeRaadt again: https://marc.info/?l=openbsd-misc&m=119318909016582
12995816
Peculiar stuff. I'm always skeptical of these security Linux distributions, but this bug is so bad that it seems like an infiltration of Qubes at best or Qubes being a honeypot at worst.
Topfi
That is sphincter tightening to read. Have to point out how amazingly well their bulletins handle communication. Clearly describes the issues, how users are to act, etc. in, what I feel, is an easy to grasp language, even if one’s not in the weeds that much. In fairness though, I do still have some past memories concerning Qubes architecture from way back, so maybe my assessment is wrong and this is still not that straight forward to grasp for most.
Allwinkt
The worst part is that in 2020 they explicitly documented that the remote filename is attacker controlled,but still allowed it to reach system() That is C security 101: never pass untrusted input through a shell. This should have been caught in review!
Allwinkt
The worst part is that in 2020 they explicitly documented that the remote filename is attacker controlled,but still allowed it to reach system() This is C security 101: never pass untrusted input through a shell. This should have been caught in the review!
ka3ki
it's kinda doomed at this point
_pdp_
Most security bugs are due to improper string validation and use.
iberator
This os is supposed to be run on bare metal AFIK for same reason
grommz
The founder Joanna Rutkowska left QubesOS in 2018. All the code involved in this bug was committed by her successor Marek Marczykowski-Górecki. Joanna seems to be a genuine good guy, she once wrote a paper titled "Intel x86 considered harmful". That's why Huawei and the Chinese government aren't even trying any more to make western CPU architectures secure, it's a hopeless cause.
anArbitraryOne
My username checks out
user_7832
Mini tangent: Could someone explain to me why Qubes is used for security, when (from what I understand) Jails on BSD is significantly more robust/safe/has a much smaller exposed area? Is it just "everyone's using linux already; here's a safer linux"?
bawolff
its kind of fascinating that all this paranoia falls to a shell escaping issue with system().
Naru41
If it's `untrusted_filename`, it should at least accept the length of the string as an argument.
crest
Really an attacker controlled system() call?!?
dhruvrrp
Tangentially, their steps listed to verify PGP signature is the prime example of why PGP has such dismal adoption.