GPU VulnDB

Database/Control plane, storage & DevOps

OpenNebula: one.vm.exec skips the permission check, letting any user run commands in other tenants' VMs

CVE-2026-84165Control plane, storage & DevOpscurated

Impact

An authenticated user with only basic permissions can call one.vm.exec against a VM belonging to someone else and have the command run inside it, with no ownership or ACL verification. The only prerequisites are the target VM's identifier - small sequential integers, so enumeration is trivial - and qemu-guest-agent enabled in that VM. On an OpenNebula cloud handing out GPU passthrough or vGPU instances, this is direct cross-tenant compromise of running training jobs: datasets, credentials, checkpoints and model weights, plus code execution on a guest that holds accelerator devices. Affects all versions prior to 7.4.

Who can reach it

Any authenticated OpenNebula user with basic permissions, over the XML-RPC/API interface. Needs the target VM's numeric id and qemu-guest-agent running in that VM; no administrative role required.

What to do

Upgrade OpenNebula to 7.4 and restart the management daemon - the fix lives in the front-end authorization path, so tenant VMs and GPU nodes do not need to be drained or rebooted. If the upgrade cannot happen tonight, removing qemu-guest-agent from tenant VM templates (and from running guests) closes the execution path, at the cost of losing guest-agent features. Review API logs for one.vm.exec calls against VMs the caller does not own.

References

Related entries

All Control plane, storage & DevOps 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.