Apache CloudStack CVE-2026-59799

Exploitation requires a valid, authenticated CloudStack user account with at minimum low-level privileges (confirmed by CVSS PR:L). The Two-Factor Authentication plugin must be enabled and in use within the CloudStack deployment - environments that have not configured or deployed the 2FA plugin are not affected by this specific flaw. The attack targets the 2FA disable flow specifically, meaning the plugin must be active for the bypass to be reachable. Network access to the CloudStack management API or UI endpoint is necessary (CVSS AV:N). Limiting factors: unauthenticated external attackers cannot exploit this without credentials; deployments that do not use CloudStack's built-in 2FA plugin (e.g., relying solely on LDAP/SAML with external MFA) are not in scope; CloudStack instances isolated to internal networks reduce exposure to the broader threat population.

The vendor-assigned CVSS of 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) reflects a network-reachable, low-complexity exploit requiring only low-privileged authentication - a realistic threat model for a multi-tenant cloud management platform where many users may hold standard user accounts. However, real-world exploitation pressure appears low: EPSS at 0.18% (8th percentile) places this well below actively targeted vulnerabilities, there is no CISA KEV listing, and no public proof-of-concept has been reported. The critical mitigating factor is PR:L - an unauthenticated external attacker cannot directly exploit this flaw; valid credentials to a CloudStack account are required. For environments where CloudStack is exposed to internal users or the internet and 2FA enforcement is a primary control, the effective risk is elevated: bypassing 2FA could enable account takeover of higher-privileged accounts if an attacker has any low-privileged foothold. The vendor-assigned A:H (Availability High) is the most debatable signal - bypassing 2FA does not directly cause service disruption and likely reflects the potential for subsequent destructive actions post-compromise rather than a direct availability impact.

An attacker holding a valid low-privileged CloudStack user account - obtained through credential theft, phishing, or account creation in a multi-tenant environment - sends a crafted request to the Two-Factor Authentication disable endpoint, exploiting the improper privilege check to successfully disable 2FA on a target account without completing the proper second-factor verification. With 2FA disabled, the attacker authenticates fully to that account and pivots to access cloud resources, virtual machines, or network configurations within the CloudStack environment. No public proof-of-concept has been identified, but the attack requires only standard HTTP API interaction with a CloudStack management server and low-privileged credentials.