Repository navigation
[Hardening] F-21: Base64-Encoded User Data Containing Plain Text Passwords in DB. #14530
Description
The required feature described as a wish
Description: The userdata parameter supplied to DeployVMCmd is stored base64-encoded (not encrypted) in DB. Base64 does not offer adequate protection for sensitive information, and in practice the decoded cloud-init frequently contains plaintext passwords (plain_text_passwd, passwd, chpasswd). Because user data is opaque to the platform, its contents cannot be selectively filtered. The field must be treated as sensitive in its entirety.
Affected Components: Management API / DB (cloud.async_job, column job_cmd_info).
Impact: Anyone with read access to the database can base64-decode the stored user data and recover any plaintext credentials the user set in their cloud-init, including passwords for accounts configured with passwordless sudo, thereby granting effective root on the guest.
Steps to Reproduce:
- Deploy an instance with cloud-init userdata that sets a user password (e.g.,
plain_text_passwdor achpasswdblock). - Query the database:
- mysql>
SELECT job_cmd_info FROM async_job WHERE job_cmd LIKE '%DeployVMCmd%' AND job_cmd_info LIKE '%"userdata":%';
- mysql>
- Base64-decode the
userdatavalue and observe the embedded credentials in cleartext.
Recommended Remediation: Redact or omit the userdata attribute from params before the toJson(params) serialization (this is the same code site that F-18 identifies for the top-level password parameter). It is recommended to treat the whole cloud-init field as sensitive, like in F-19.
See more examples:
Activity
github-actions commentedon Oct 30, 2026
Warning
threat detection engine error
The threat detection engine encountered an error and could not complete analysis. This is a tooling failure, not a security finding.
What happened
The threat detection engine failed to produce results.
Review the workflow run logs for details.
🎯 Triage report
The report says the
userdataparameter ofDeployVMCmdis stored base64-encoded in theasync_job.job_cmd_infocolumn, so anyone with DB read access can decode cloud-init content that often includes plaintext passwords. The suggested fix is to redactuserdatabefore the params are serialised inApiServer. The same pattern is in F-18 and F-19 of this hardening series.Scope check for maintainers:
THREAT_MODEL.md§3 item 6 and Q10 say user-data is tenant-controlled guest customisation and is not a CloudStack-side injection surface. §9 says the database is trusted for its own security, but credential handling is in scope. Whether leaking tenant user-data via DB read access is in scope needs a maintainer decision.Reporting channel:
SECURITY.mdasks for suspected vulnerabilities to be reported privately to security@apache.org and not in public issues. Maintainers may want to confirm whether this report should be handled there.📊 Assessment
job_cmd_infoinasync_job; the redaction point is in the API layer🔗 Similar issues
updateAsyncJobStatus) #13301 (related) — sensitive password leak in async job status update logging (updateAsyncJobStatus); same class of issue💡 Notes and suggestions
DeployVMCmdparams.Add this agentic workflow to your repo
To install this agentic workflow, run