Apache CloudStack CVE-2026-50112: Metalink crossed into KVM host root
A User-role tenant could bypass validation of nested Metalink URLs, trigger SSRF and reach root command execution on a shared KVM compute host.
- AUTHOR
- Karol Rapacz / CEO Breachroad · OSCP · PNPT
- PUBLISHED
- 22 August 2026
- READING TIME
- 19 min read
- TOPIC
- Cloud, Infrastructure and DevSecOps
On 22 August, the public CVE-2026-50112 record was updated after Apache published its advisory a day earlier. This is a vulnerability where a small difference between validating an outer address and validating nested addresses breaks a cloud boundary. An authenticated Apache CloudStack tenant with the default User role can register a template that points to a Metalink document, while the URLs inside that document are not checked again against the scheme allowlist.
The consequences include two related paths. A Secondary Storage VM may retrieve internal resources, creating SSRF and allowing a response to be persisted as a template that can later be downloaded through normal APIs. In a KVM environment, the Metalink and NFS path can instead lead to command execution as root on the hypervisor host, including a host that serves other tenants’ machines. This is not compromise of one guest VM; it is cross-tenant risk at the compute layer.
Affected and fixed releases
Apache identifies 4.14.0.0 through 4.20.3.0 and 4.21.0.0 through 4.22.1.0 as affected. Fixes are available in 4.20.3.1, 4.22.1.1 and later. Administrators must establish the Management Server and KVM agent versions rather than assume that an updated management interface means every dataplane component is current.
KVM environments with public template-registration APIs, tenant accounts, directDownload=true, or Metalink and NFS processing deserve the highest priority. SSRF through a Secondary Storage VM remains important without KVM because that system VM may reach management networks, storage, cloud metadata and services that guest networks cannot access.
Do not broaden the advisory to every CloudStack configuration without evidence. It describes specific template workflows and the KVM hypervisor. Inventory should distinguish management, Secondary Storage VMs, KVM agents, NFS, direct download and egress instead of assigning one status to every cluster.
Why a Metalink container changes the trust model
A Metalink document describes a file and potentially several mirrors. A user supplies the document URL, but a downloader makes further decisions from its content. Validating only the outer URL checks the wrapper, not the actual retrieval destinations.
This is a parser–fetcher trust failure. The API layer may permit HTTPS to an expected domain, while a document obtained there contains a scheme or host that policy would reject if submitted directly. When an agent forwards the nested address, the trust boundary moves from the Management Server to the KVM agent or Secondary Storage VM.
An allowlist must run after every redirect and for every resolved source, considering both scheme and network destination. Blocking one protocol alone does not prevent SSRF to loopback, link-local or a management segment over permitted HTTP. DNS may also change between validation and use, so the fetcher requires controls at the point of the actual connection.
Why the User role is not a minor privilege
A cloud tenant is legitimately allowed to create resources, images and machines. That is broad control of a dataplane, not authority over the host. CVE-2026-50112 turns normal template registration into input for a privileged component. The management API is merely the first stage; later work is performed by an agent that can reach storage and the hypervisor operating system.
Risk assessment therefore needs the number of tenant accounts, self-service template permissions, host sharing and the value of neighbouring workloads. One compromised developer account could become a route to many customers. A private enterprise cloud may still cross departmental and data-zone boundaries.
Assessing exposure without a dangerous test
Start with versions and configuration. Identify KVM zones, Secondary Storage VMs, roles allowed to register templates, direct-download use and permitted URL types. Review API history for template and ISO registration, URL fields, .metalink documents, initiating accounts and the hosts that performed downloads.
Do not recreate code execution on a production hypervisor. A safe regression test can use an isolated environment without workloads and a harmless prohibited destination to confirm a nested document URL is rejected. The expected result is a controlled policy error, not a connection to a management service or a file written to the host.
In telemetry, look for a mismatch between an outer Metalink URL and inner hosts or schemes, downloads from private, link-local or loopback addresses, unexpected NFS mounts, KVM-agent child processes and files created outside template-handling directories. Correlate the Management Server, SSVM, hypervisor and storage through a shared job or template identifier.
Upgrade plan
Back up management configuration and the database according to CloudStack procedures, treating that snapshot as a recovery mechanism rather than mitigation. Select a path to 4.20.3.1 or 4.22.1.1. In staging, validate ordinary template registration, redirects, mirror failover, checksums, direct download and the lifecycle of existing images.
Rollout should cover the Management Server, relevant System VMs and agents as specified by release documentation. Confirm the actual running versions afterwards. In HA deployments, avoid leaving an old node available to receive part of the traffic.
If patching must wait, temporarily remove external-URL template registration from non-administrative roles, disable unnecessary direct download and restrict egress from SSVMs and KVM hosts. Network policy should prevent downloader access to management endpoints, metadata, loopback and infrastructure segments. These controls reduce reach, but Apache recommends upgrading because an edge filter cannot reliably cover every semantic variant.
Responding to possible hypervisor compromise
A suspicious Metalink demands more than deleting a template. Preserve API records, document content, agent logs, processes, connections, mount history and host package integrity. Isolate the hypervisor from new scheduling, but consider volatile evidence and running VMs before powering it down.
If root execution is confirmed, assume host trust is lost. Workload migration, rebuild from a trusted image, rotation of credentials reachable by the host and assessment of neighbouring tenants are safer than deleting one artifact manually. Examine the SSVM, NFS and Management Server too because the chain crosses several planes.
An unusual URL alone is not proof of compromise. Legitimate repositories use mirrors and redirects. The reached destination, persisted file, process activity and timing alignment between API and host determine the conclusion.
Apache facts and Breachroad conclusions
Affected releases, the User role, SSVM SSRF, cross-tenant root on KVM and fixed versions come from the Apache advisory. The record update on 22 August does not mean the flaw originated today; today’s development is its full public description and distribution into vulnerability feeds.
Downloader segmentation, telemetry correlation, safe regression testing and hypervisor rebuild guidance are Breachroad conclusions. Cybersecurity training for technical teams develops this trust-chain analysis, while a cloud security assessment can validate roles, System VMs, egress, KVM, storage and update evidence.
