CRITICAL: Kubernetes Image Builder Flaw Leaves Default SSH Credentials on VM Images

If you have ever used Kubernetes Image Builder to create virtual machine images for your clusters, you might want to check whether those images shipped with a password that literally everyone knows. CVE-2024-9486 is exactly as bad as it sounds: a critical vulnerability that leaves default SSH credentials baked into VM images, giving any attacker on the network root-level access to your nodes. The CVSS score of 9.8 tells you everything you need to know about how seriously you should take this.

The vulnerability affects the Kubernetes Image Builder project, a tool that automates the creation of VM images for use with Kubernetes clusters running on various infrastructure providers. When building images using the Proxmox provider, the tool creates a default user account called "builder" with a well-known default password. The problem is that this account and its credentials persist in the finished image rather than being removed during the build finalization process. Anyone who deploys a VM from that image inherits the vulnerability, and anyone who knows the default password can SSH in with root privileges.

The scope here is significant because Image Builder supports multiple output formats and infrastructure targets. While the critical CVE-2024-9486 specifically affects the Proxmox provider, the underlying issue extends to other providers as well. CVE-2024-9594, rated at CVSS 6.3, covers the same default credential problem in images built for Nutanix, OVA, QEMU, and raw formats. The lower severity score reflects the fact that these providers require different attack scenarios to exploit, but the fundamental flaw is identical: credentials that should be ephemeral end up permanent.

The "builder" account exists for a legitimate reason during the image creation process. Image Builder needs a way to SSH into the VM while it is being configured, installing packages, applying security settings, and preparing the system for its eventual role in a Kubernetes cluster. The account is supposed to be removed or disabled before the image is finalized. In vulnerable versions, that cleanup step either fails silently or never happens at all, leaving a backdoor that attackers can walk right through.

Exploitation requires network access to a VM built with a vulnerable image, which might sound like a limiting factor until you consider how Kubernetes clusters are typically deployed. Nodes often share network segments with other workloads, and in cloud environments, network boundaries can be more porous than administrators realize. An attacker who compromises any workload in the same network neighborhood as a vulnerable node can pivot through the default credentials to gain root access. From there, they have everything they need to compromise the Kubernetes control plane, steal secrets, deploy cryptominers, or establish persistent access for later use.

The Kubernetes Security Response Committee coordinated disclosure and patching with the Image Builder maintainers. Fixed versions are available: Image Builder version 0.1.38 addresses CVE-2024-9486 for the Proxmox provider, while version 0.1.39 and later resolves the broader CVE-2024-9594 across all affected providers. Organizations running vulnerable versions need to do more than just update the tool, though. Any images previously built with affected versions still contain the default credentials. Those images need to be rebuilt from scratch using the patched Image Builder, and VMs deployed from the old images need to be replaced or manually remediated.

Manual remediation for existing deployments involves disabling the builder account on each affected VM. This can be accomplished by running "usermod -L builder" to lock the account, but that approach assumes you can identify every VM that was built with a vulnerable image. In large environments with extensive automation, that accounting exercise can be surprisingly difficult. Rebuilding and redeploying is often cleaner, even if it requires more upfront effort.

The timing of this disclosure is worth noting. The vulnerability was actually discovered and patched in late 2024, but exploitation in the wild has continued into 2026 because many organizations never updated their Image Builder installations or rebuilt their base images. Security researchers have observed scanning activity targeting the default credentials, indicating that attackers are actively looking for vulnerable deployments. The long tail on this vulnerability is a reminder that patching the tool is not the same as patching the output.

For organizations using Kubernetes Image Builder, the immediate action items are straightforward. First, verify which version of Image Builder your environment is running. If it is older than 0.1.38 for Proxmox or 0.1.39 for other providers, update immediately. Second, inventory all VM images that were created with the vulnerable tool and flag them for replacement. Third, audit running VMs for the presence of the builder account and either disable it manually or schedule those VMs for replacement. Finally, review network segmentation around your Kubernetes nodes to ensure that even if a vulnerability like this exists, attackers cannot easily reach the affected systems.

The broader lesson here applies to any infrastructure-as-code tooling that handles credentials during the build process. Temporary accounts, bootstrap passwords, and provisioning secrets are necessary evils in automated deployments, but they need robust cleanup mechanisms that fail loudly rather than silently. When a tool is designed to remove sensitive material before finalizing an image, that removal should be verified programmatically rather than assumed. The difference between a secure image and a compromised one can be a single missed step in the build pipeline.

Kubernetes adoption continues to accelerate across enterprises of all sizes, and with that adoption comes an expanding attack surface. The Image Builder vulnerability demonstrates that security risks in the container ecosystem extend beyond the runtime environment into the foundational tooling that creates cluster infrastructure. Organizations that focus exclusively on container scanning and runtime protection may miss critical vulnerabilities in the build pipeline itself.

If your Kubernetes infrastructure relies on custom VM images, this is a good time to audit how those images are created, what credentials they contain at various stages, and whether your build process includes verification steps to ensure sensitive material is removed before images go into production. The attackers scanning for default SSH credentials are counting on you not to bother.