| 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. > 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. |
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.