Apache CloudStack: unsanitized backup repository options inject OS commands onto the KVM hypervisor host

Impact

The NAS backup provider passes repository mount options straight through without sanitisation, so an account with operator privileges can plant shell metacharacters in a backup repository definition. The injected command runs on the KVM hypervisor host the next time any account performs a backup restore - a delayed trigger fired by a different, innocent user. That is code execution on the hypervisor itself, underneath every VM it hosts, including any guest with passed-through GPUs; recovering means treating the host as compromised and draining it. The vulnerable APIs exist since 4.20.0.0 (addBackupRepository) and 4.22.0.0 (updateBackupRepository).

Who can reach it

An authenticated CloudStack operator (admin-level) account able to call addBackupRepository or updateBackupRepository. Execution happens later, on the hypervisor host, when any account runs a backup restore - the attacker does not need hypervisor access themselves.

What to do

Upgrade CloudStack to 4.20.3.1 or 4.22.1.1 or later; affected ranges are 4.20.0.0 through 4.20.3.0 and 4.21.0.0 through 4.22.1.0. This is a management-server upgrade and restart rather than a hypervisor reboot, but audit existing backup repository definitions for injected options before the first restore after upgrading, and review operator accounts and hypervisor hosts that have run restores.

References