So, not being vulnerable is dependent on not doing something that can make you vulnerable? That doesn't seem right. If you can do something to make yourself vulnerable, you are vulnerable.
RedHat states "This could lead to data integrity issues or unexpected behavior during cryptographic operations, impacting the reliability of encrypted communications for local users." as the impact.
To be completely fair, any kind of sandboxing inside of Qubes's VMs do not mean much, because it is on X11. Any app can pwn any other app lol.
With that being said, yeah, he's being disingenuous as per usual for sure. Part of Qubes hardening is trying to not allowing an attacker to gain root to make it harder to attack Xen, but our evangelist here claims it doesn't matter if an attacker has root :)
> So, not being vulnerable is dependent on not doing something that can make you vulnerable? That doesn't seem right. If you can do something to make yourself vulnerable, you are vulnerable.
On the one hand, you are right, and I rather meant "not exploitable", since technically the vulnerability is still there. On the other hand, yes, any security does rely on you not doing something stupid like "curl | sudo bash".
> "In-VM attack only". That's disingenuous.
It's really not. Hardening of guest OSes is out of scope of Qubes. You are supposed to not combine trusted and untrusted actions in a single VM, so intra-VM security is really secondary. I really recommend you to read my link about organizing the workflows.
You have a good point concerning the integrity issues though.
> On the one hand, you are right, and I rather meant "not exploitable", since technically the vulnerability is still there.
And I'm fine with that. I think, the Qubes OS notices should use that terminology as well. Though, some of the vulnerabilities are exploitable, if you don't follow the Qubes OS guides to the T.
> https://www.qubes-os.org/news/2026/04/28/xsas-released-on-20...
Looking at just that small list, they mark some vulnerabilities as not vulnerable because it's "In-VM attack only". That's disingenuous.
> There is no way to use the discussed vulnerability, if one uses Qubes according to docs
It's like saying you're not vulnerable to cutting yourself with a knife, as long as you use it correctly.
You can say your risk is low, but you can't say you're not vulnerable.
---
> Moreover, there is no sudo password by design
The POC uses `/usr/bin/su`, but that's besides the point.
The vulnerability itself can affect other things. The POC just used root-privilege escalation as an example.
https://access.redhat.com/security/cve/cve-2026-31431
RedHat states "This could lead to data integrity issues or unexpected behavior during cryptographic operations, impacting the reliability of encrypted communications for local users." as the impact.