On Fri, Aug 28, 2026 at 07:22:51AM -0500, Henrik Ahlgren wrote:
> > Thank Lucas for the suggestion to use bubblewrap. The list of command-line
> > arguments is a bit intimidating, but I will try to try it.
>
> Unfortunately, even full VMs are not entirely secure:
>
> https://blog.trailofbits.com/2026/08/26/vms-wont-contain-cyber-capable-agents/
One interesting observation from this blog post is that all of the
exploits found by the AI was patched upstream, but unfortunately not
in the distribution kernel (the OP was using Debian oldstable).
Quoting from the blog:
A distribution with rapid updates is now a requirement. I love
older, stable software, but the cycle of backporting patches is
simply too long. An older distribution (like Debian 12, my old
standby) that isn’t getting immediate upstream updates should be
assumed vulnerable. A competent agent will discover these bugs
quickly and synthesize target-specific exploits.
The fact that all of the KVM escapes, especially the kernel-side
issues, were already in upstream is actually quite heartening, and
probably reflects work being done by *all* of the hyperscalers to find
the potential problems that might be found using an LLM (in most
cases, by using an LLM) and fixing the bugs post-haste, and then
sending the patches upstream. After all, if you are offerring a VM as
a service to anyone who can provide a credit card, you do *not* want
to leave yourself vulnerable to 0-day attacks.
At this point I would *not* recommend that someone use an LTS older
than a year, maybe two at the most. The reason for that is that many
of the bug fixes may not apply cleanly in the older LTS kernels, and
backporting to an older LTS kernel is on a best-efforts basis.
We might want to consider making the latest LTS kernels available to
the Debian oldstable and oldoldstable, and actively encourage our
users to move to Debian stable sooner rather than later.
Cheers,
- Ted
P.S. Because of the risk of KVM escape, a *really* good idea is to
combine the use of a KVM with the use of something like seccomp-bpf to
put an additional layer around the VMM. That way, even if an attacker
can break through the KVM layer and gain code execution in the VMM,
hopefully the secondary sandboxing layer will prevent the attacker
from breaking root on the host OS.
