CVE-2026-59657: Apache CloudStack Information Disclosure

CVE-2026-59657 Overview

CVE-2026-59657 is a cleartext storage of sensitive information vulnerability in Apache CloudStack. The flaw resides in the AsyncJob subsystem, which persists asynchronous job data to the CloudStack management database without encryption. Sensitive parameters passed through AsyncJob calls can therefore be recovered by any actor with read access to the database.

The vulnerability affects Apache CloudStack versions 4.0.0 through 4.20.3.0 and 4.21.0.0 through 4.22.1.0. Apache has released fixed builds in versions 4.20.3.1 and 4.22.1.1. The issue is tracked as [CWE-312: Cleartext Storage of Sensitive Information].

Critical Impact
Sensitive job parameters, including credentials and secrets passed to CloudStack orchestration APIs, are stored in cleartext in the AsyncJob database tables and can be retrieved by attackers with database access.

Affected Products

Apache CloudStack 4.0.0 through 4.20.3.0
Apache CloudStack 4.21.0.0 through 4.22.1.0
Deployments using the MySQL/MariaDB backend for the CloudStack management server

Discovery Timeline

2026-08-21 - CVE-2026-59657 published to NVD
2026-08-27 - Last updated in NVD database

Technical Details for CVE-2026-59657

Vulnerability Analysis

Apache CloudStack uses an AsyncJob framework to track long-running orchestration tasks such as virtual machine provisioning, volume operations, and template management. Each job is persisted to the async_job table along with its request parameters and response payload. These records are written without applying encryption or redaction to sensitive fields.

API callers routinely pass secrets through AsyncJob parameters. Examples include hypervisor credentials, template registration URLs with embedded tokens, LDAP bind passwords, and cloud provider API keys used by CloudStack plugins. Because the framework treats all parameters uniformly, these values land verbatim in the database and remain retrievable long after job completion.

An attacker who reaches the CloudStack database, whether through a stolen operator credential, a misconfigured backup, a compromised replica, or a separate SQL injection flaw, can query historical AsyncJob rows and harvest these secrets. The impact is limited to confidentiality, but the recovered credentials often unlock adjacent hypervisors, storage systems, and identity providers.

Root Cause

The root cause is the absence of field-level encryption and parameter scrubbing in the AsyncJob persistence layer. CloudStack serializes the full API command context to the database for job recovery and audit purposes, and the schema does not distinguish sensitive fields from operational metadata.

Attack Vector

Exploitation requires read access to the CloudStack management database. Attack paths include database credentials exposed in configuration files, replicated backups stored without encryption, insider access from operators with query privileges, and chained exploitation from other vulnerabilities that yield SQL execution. No authentication to the CloudStack API itself is required once database access is obtained.

See the Apache CloudStack security advisory for vendor guidance and additional technical detail.

Detection Methods for CVE-2026-59657

Indicators of Compromise

Unexpected SELECT queries against the async_job, async_job_join_map, or related job tables from accounts that do not normally read them.
Outbound access to the CloudStack MySQL/MariaDB port 3306 from hosts that are not the management server.
Reuse of hypervisor, LDAP, or cloud provider credentials from source IPs that do not match the CloudStack management plane.
Presence of unencrypted CloudStack database dumps in backup shares, developer laptops, or cloud object storage.

Detection Strategies

Audit database query logs for reads against AsyncJob tables and correlate against the list of approved operator accounts.
Search existing CloudStack databases for cleartext credential patterns in the cmd_info and result columns of async_job to establish exposure scope.
Monitor for anomalous authentications to hypervisors and integrated systems using credentials known to have been passed through CloudStack APIs.

Monitoring Recommendations

Enable MySQL general query logging or audit plugin coverage on the CloudStack schema and forward logs to a central analytics platform.
Alert on database connections originating outside the management server subnet.
Track credential rotation status for every secret ever submitted to CloudStack until rotation is confirmed post-upgrade.

How to Mitigate CVE-2026-59657

Immediate Actions Required

Upgrade Apache CloudStack to 4.20.3.1, 4.22.1.1, or later as directed by the Apache advisory.
Rotate every credential that was previously submitted through CloudStack APIs, including hypervisor, storage, LDAP, and cloud provider secrets.
Restrict access to the CloudStack management database to the management server host only and remove any lingering operator read privileges.
Re-encrypt or purge existing database backups that contain pre-patch AsyncJob rows.

Patch Information

Apache CloudStack 4.20.3.1 and 4.22.1.1 remediate the issue by removing cleartext storage of sensitive AsyncJob parameters. Administrators running any release in the 4.0.0–4.20.3.0 or 4.21.0.0–4.22.1.0 ranges must upgrade. Refer to the Apache mailing list advisory for release notes and upgrade procedures.

Workarounds

Enable transparent data encryption or filesystem-level encryption on the MySQL/MariaDB volume hosting the CloudStack schema.
Enforce network-level isolation so only the CloudStack management server can reach the database port.
Periodically truncate completed AsyncJob rows through supported CloudStack cleanup jobs to shrink the window of exposure until the patch is applied.
Store CloudStack integration secrets in an external vault and reference them indirectly where CloudStack supports it, reducing the volume of secrets that transit AsyncJob.

bash

# Configuration example: restrict CloudStack database access to the management host
# On the MySQL/MariaDB server (adjust user, host, and schema to match deployment)
mysql -u root -p <<'SQL'
REVOKE ALL PRIVILEGES ON cloud.* FROM 'cloud'@'%';
FLUSH PRIVILEGES;
CREATE USER IF NOT EXISTS 'cloud'@'mgmt.internal' IDENTIFIED BY 'REPLACE_WITH_STRONG_SECRET';
GRANT SELECT, INSERT, UPDATE, DELETE, EXECUTE ON cloud.* TO 'cloud'@'mgmt.internal';
FLUSH PRIVILEGES;
SQL

# Firewall rule: allow only the management server to reach MySQL
iptables -A INPUT -p tcp --dport 3306 -s 10.0.0.10 -j ACCEPT
iptables -A INPUT -p tcp --dport 3306 -j DROP