GPU VulnDB

Database/Kernel, userspace & hypervisor

QEMU Guest Agent: symlink and TOCTOU flaws in SSH key injection give root inside the guest

CVE-2026-12080Kernel, userspace & hypervisorcurated

Impact

qemu-ga runs as root inside the guest. An unprivileged guest user can pre-stage a directory symlink, or win a time-of-check/time-of-use race on a file symlink, so that a guest-ssh-add-authorized-keys call hands them ownership of an arbitrary root-owned file or directory - and from there, root in the guest. The escalation is guest-local: on its own it does not reach the host or another VM. For GPU clouds that rent whole VMs with passthrough accelerators the tenant is typically already root in their own VM, so the exposure is really on guests with multiple accounts - shared research VMs, multiuser images, or GPU VMs whose interactive users are deliberately kept unprivileged. The path only opens when an external management layer such as libvirt actually invokes the command.

Who can reach it

Local unprivileged user inside a guest running qemu-ga, on a platform where libvirt or another management layer calls guest-ssh-add-authorized-keys. No host or hypervisor access required.

What to do

Update the qemu-guest-agent package inside guest images and restart the agent. This is a guest-side package rather than a host QEMU update, so it rolls out with a golden-image refresh and per-guest restart - no hypervisor maintenance window and no GPU node reboot. Where images cannot be refreshed quickly, block the guest-ssh-add-authorized-keys command via the qemu-ga allow/block list. Red Hat's CVE page carries the per-RHEL fixed builds; the NVD record names no fixed version.

References

Related entries

All Kernel, userspace & hypervisor entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.