CVE-2024-9486

What it actually does

Default credentials remain enabled in VM images produced by the Proxmox provider in Kubernetes Image Builder versions <= v0.1.37, granting root shell access to any node instantiated from those images.

Why it matters to the business

Compromised nodes expose entire Kubernetes clusters to unauthorized root access, risking workload takeover, data exfiltration, and operational disruption; prevalence across downstream image consumers amplifies exposure.

How an attack unfolds

An attacker locates nodes built from vulnerable Proxmox images, connects using the known default credentials, obtains root, and pivots into the cluster control plane or workloads.

How to fix it

Upgrade to kubernetes-sigs/image-builder commit 09aedcd7e36cddacdb2d5ea7532003f39bf7bb57 or newer, rebuild all affected images with the Proxmox provider, and redeploy nodes from the new images.

How to confirm the fix worked

Confirm Image Builder version used in builds is at or above the fixed commit; test resulting images to ensure default credentials are disabled; review node SSH and authentication configurations.

Typical attack path

1. Locate reachable Kubernetes nodes created from Proxmox images built with vulnerable Image Builder
2. Authenticate using the enabled default credentials to obtain an initial shell
3. Escalate privileges to root and enumerate cluster resources
4. Deploy persistence, move laterally, or exfiltrate data

How to detect it

Review Image Builder logs and build artifacts for versions <= v0.1.37 using the Proxmox provider; inspect node authentication logs for successful logins with default credential patterns.

What your security team should do

• Rebuild and replace all Proxmox-based VM images using the fixed Image Builder commit immediately
• Audit existing nodes for acceptance of default credentials and rotate or remove them
• Add build pipeline checks to enforce updated Image Builder versions
• Monitor authentication logs on nodes for anomalous root logins