Apache CloudStack EUVD-2026-63835

Exploitation requires a CloudStack deployment running the Kubernetes Service (CKS) plugin in a multi-tenant configuration, and the attacker must be able to issue CKS node add/remove operations - realistically meaning they hold a valid tenant/account on the target CloudStack instance (the 'cross-tenant' framing implies at least tenant-level access even though the vendor vector states PR:N). The concrete trigger is the cluster node add-and-remove workflow, where account ownership is not enforced. Limiting factors: single-tenant or non-CKS CloudStack deployments are not exposed, only versions 4.21.0.0 through 4.22.1.0 are affected, and 4.22.1.1+ removes the flaw; there is no user-interaction requirement and attack complexity is low.

The signals conflict and warrant judgment rather than blind reliance on the 9.1 score. The vendor CVSS vector (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:N) rates this Critical with no privileges required, yet the description explicitly frames the flaw as 'cross-tenant' manipulation - which implies the attacker must already hold a valid tenant account on the CloudStack instance, i.e. some authentication is realistically needed (verify PR:N with the vendor; it likely understates the access requirement). Countervailing that Critical rating, EPSS is only 0.13% (3rd percentile), there is no KEV listing and no known public exploit, indicating no evidence of widespread or active exploitation. That said, the impact - breaching tenant isolation in a cloud orchestration platform - is severe for any operator running CloudStack as a shared multi-tenant service, so even a mid-sized service provider should treat this as a high-priority patch given the trivial upgrade path. Also note A:N despite the flaw involving removing nodes, which would plausibly degrade a victim cluster's availability; the official vector may understate availability impact.

An attacker who holds an ordinary tenant account on a shared CloudStack cloud crafts a CKS node add/remove API request that references another tenant's Kubernetes cluster; because ownership is not enforced, CloudStack executes the operation against the victim tenant's cluster. The attacker can thereby inject attacker-controlled nodes into, or strip nodes out of, a cluster they do not own - undermining that tenant's cluster integrity and availability. No public exploit code is known, but the low attack complexity means a knowledgeable tenant could reproduce it against a vulnerable multi-tenant deployment.