Skip to content

[Hardening] F-13: Weak Default Password and Database Encryption Key. #13341

Description

@davift

The required feature described as a wish

Image

Description: CloudStack ships with a default administrative password and database encryption key, both set to the string "password". Neither value is randomized at install time, and the administrator is not prompted to change them during setup. Note that the database encryption key cannot be changed afterwards.

Affected Components: Management

Impact: An attacker with knowledge of the default credentials, which are publicly documented, can authenticate to the CloudStack Management UI without any prior reconnaissance or effort. Additionally, if the database encryption key is not changed, an attacker who gains read access to the database (e.g., via SQL injection, a misconfigured backup, or direct server access) can decrypt all protected fields, including API secret keys, passwords, and other credentials, using the known default key.

Steps to Reproduce:

  • Deploy a fresh CloudStack instance following the official documentation.
  • Attempt to log in using the username admin and the password password.
  • Observe that login succeeds without any prompt to change the default password.
  • Separately, inspect the database encryption key on the management server:
  • $ cat /etc/cloudstack/management/key
  • Observe that the encryption key is set to the default value password.

Recommended Remediation: Generate a unique password and database encryption key from a reliable source of entropy during installation (before the system becomes operational). Neither value should have a usable default.

Activity

  1. weizhouapache commented on Jun 4, 2026

    @weizhouapache
    Member

    for the management key and database encryption key, user can specify them when run setup-cloudstack-database
    users are also able migrate cloudstack database with new management key or database key by migrate-cloudstack-database.

    despite it, I think the suggestion makes sense.

  2. davift commented on Jun 4, 2026

    @davift
    Author

    for the management key and database encryption key, user can specify them when run setup-cloudstack-database users are also able migrate cloudstack database with new management key or database key by migrate-cloudstack-database.

    despite it, I think the suggestion makes sense.

    Hey Wei, I did not know that. I will read more about this command migrate-cloudstack-databas. Thank you!

  3. weizhouapache commented on Jun 4, 2026

    @weizhouapache
    Member

    for the management key and database encryption key, user can specify them when run setup-cloudstack-database users are also able migrate cloudstack database with new management key or database key by migrate-cloudstack-database.
    despite it, I think the suggestion makes sense.

    Hey Wei, I did not know that. I will read more about this command migrate-cloudstack-databas. Thank you!

    @davift
    sorry, the correct command is cloudstack-migrate-database
    You may refer to
    https://cwiki.apache.org/confluence/display/CLOUDSTACK/New+database+encryption+cipher+-+AeadBase64Encryptor
    https://www.shapeblue.com/new-cloudstack-database-encryption-engine/

  4. daviftorres commented on Jun 10, 2026

    @daviftorres
    Contributor

    I will just drop the example steps here for those who say TLDR.

    systemctl stop cloudstack-management
    systemctl stop cloudstack-usage
    mysqldump --no-tablespaces --lock-tables=false -R cloud > cloud.sql
    mysqldump --no-tablespaces --lock-tables=false -R cloud_usage > cloud_usage.sql
    cloudstack-migrate-databases -d "password" -m "password" -e "<new_db_key>" -n "<new_mgmt_key>"
    systemctl start cloudstack-management
    systemctl start cloudstack-usage
  5. weizhouapache commented on Jun 11, 2026

    @weizhouapache
    Member

    I will just drop the example steps here for those who say TLDR.

    systemctl stop cloudstack-management
    systemctl stop cloudstack-usage
    mysqldump --no-tablespaces --lock-tables=false -R cloud > cloud.sql
    mysqldump --no-tablespaces --lock-tables=false -R cloud_usage > cloud_usage.sql
    cloudstack-migrate-databases -d "password" -m "password" -e "<new_db_key>" -n "<new_mgmt_key>"
    systemctl start cloudstack-management
    systemctl start cloudstack-usage

    @davift
    Before migrating the database, it is recommended to back up the /etc/cloudstack/management directory as well, including the key and db.properties files.

  6. added this to the 4.24.0 milestone on Jun 16, 2026
  7. github-actions commented on Aug 19, 2026

    @github-actions

    🎯 Triage report

    Requests that CloudStack randomize the default admin password and database encryption key at install time instead of shipping both as the well-known string "password". A maintainer confirmed the key/password can already be customized via setup-cloudstack-database/cloudstack-migrate-databases, but agreed the suggestion (safer defaults, no usable default) has merit.

    📊 Assessment

    Dimension Value Reasoning
    Type type:enhancement Hardening/installation-flow improvement request, not a functional defect.
    Component component:management-server Affects installation/setup and encryption-key handling in the management server.
    Severity n/a Hardening enhancement, not a bug with a severity.
    Labels type:enhancement, component:management-server See above
    Coding agent Needs more info Underlying tooling already exists (cloudstack-migrate-databases); the actual change (prompting for/generating a random key and admin password at install/setup time) needs a maintainer decision on backward compatibility and packaging/installer flow before implementation.
    💡 Notes and suggestions

    Related docs already exist on rotating the DB encryption key: (cwiki.apache.org/redacted) . Consider whether this issue should be scoped down to "installer prompts for/generates secure defaults" rather than changing runtime defaults.

    Generated by Daily Issue Triage · sonnet50 262K · ◷

    Add this agentic workflows to your repo

    To install this agentic workflow, run

    gh aw add githubnext/agentics/workflows/daily-issue-triage.md@d7c1dc4b72b00607a67caaffdcc216cb64379cf9
    
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions