CVE-2022-2084 - How Cloud-Init Logs Could Leak Sensitive Data (Including Hashed Passwords) Before v22.3

Cloud-init is a backbone tool for many cloud deployments, automatically handling initial system configuration when a machine boots for the first time. But before version 22.3, a serious vulnerability known as CVE-2022-2084 was present. This bug could lead to sensitive data exposure—including *hashed passwords*—in logs that might be accessible to anyone with a login.

In this article, we’ll explore the vulnerability in simple terms, show how the leak can happen, look at sample code and log output, and offer practical advice to stay protected. This content aims to be an exclusive, easy-to-understand breakdown:

What Is Cloud-Init? (A Quick Primer)

Cloud-init is software used across clouds (AWS, Azure, OpenStack, etc.) to automatically set up machines—users, SSH keys, networking, and more—according to a YAML file it reads at first boot.

The Vulnerability: CVE-2022-2084 in Simple Terms

Between versions up to 22.2, cloud-init does strict checks on the configuration file's schemas. When an error occurs, cloud-init tries to report *why* parsing failed—by dumping the bad part of the config file right into its log.

Here's the issue:  
If your config had sensitive data (like hashed passwords) in it, and you made a typo or schema mistake, the *entire section*—including the secret—could end up in the log file, which is world-readable by default at /var/log/cloud-init.log.

Imagine you provide a user creation entry

users:
  - name: alice
    password: $6$MySecretHashedPass
    ssh-authorized-keys:
      - ssh-rsa AAAAB...
    shell: /bin/bash

If you made a syntax mistake—maybe a missing quote or an extra colon—cloud-init rejects the config.

What happens next?
Cloud-init logs the *exact yaml snippet* of your bad users section—*including the hashed password*—to help with debugging. But anyone with basic access to the system can now read that log file and see your password hash.

Before the patch, a log snippet from /var/log/cloud-init.log might look like

2022-05-01 08:33:21,473 - util.py[WARNING]: Failed to load user data: schema validation failed
2022-05-01 08:33:21,473 - util.py[WARNING]: Error in 'users' section:
  - name: alice
    password: $6$MySecretHashedPass
    ssh-authorized-keys:
      - ssh-rsa AAAAB...
    shell: /bin/bash
  ^

Exploit Anatomy

Who is at risk?  
Any environment where users or attackers can read /var/log/cloud-init.log. This is especially worrying in cloud platforms that give shell access to multiple (untrusted) users.

Admin mistakes a cloud-init config (typo in the "users" section).

2. Cloud-init logs the faulty block, including the secret password hash, to /var/log/cloud-init.log.
3. Attacker gains non-root shell (for example, using a less-privileged account or via a running app).

`bash

grep password /var/log/cloud-init.log

The Fix

cloud-init v22.3 fixes CVE-2022-2084 by sanitizing the logs, ensuring that schema failure reports *no longer dump arbitrary config data* in world-readable logs.

Secure versions:  
| cloud-init Version | Status       |
|--------------------|--------------|
| ≤ 22.2             | Vulnerable   |
| ≥ 22.3             | Patched      |

PATCH IMMEDIATELY: Upgrade to cloud-init v22.3 or newer.

- On Ubuntu/Debian:

`sh

sudo chmod 600 /var/log/cloud-init.log

*Note: This may break troubleshooting for some non-root users.*

3. Audit Existing Logs: Grep for sensitive fields (e.g., password:) in all old cloud-init logs and secure or delete them.
4. Avoid Putting Sensitive Data in User-Data: Prefer passing secrets via instance metadata or other secure vault methods where possible.

References

- CVE-2022-2084 on NVD
- cloud-init GitHub issue #1582
- cloud-init v22.3 Changelog

Conclusion

CVE-2022-2084 is a classic example of how helpful debugging features can sometimes create new risks—especially when secrets are involved. If you’re running cloud-init earlier than v22.3, prioritize pathing ASAP, and always watch what goes into logs!

If you’re a cloud sysadmin, take a few minutes today to check your versions and audit those logs. It might save you a headache tomorrow.

Timeline

Published on: 04/19/2023 22:15:00 UTC
Last modified on: 05/01/2023 17:39:00 UTC