Image Builder credentials crossed the boundary into node images

A credential needed to construct a virtual-machine image should not become an access path into every node created from that image. The October 14 Kubernetes advisory describes exactly that failure in Image Builder's Proxmox provider. Default credentials remained enabled in the resulting images. An unauthorized user able to reach a node could use those credentials, and the project says they could lead to root access.

The same announcement covers a related but different exposure on several other providers. CVE-2024-9486 concerns the Proxmox images with credentials retained after construction. CVE-2024-9594 concerns vulnerable build-time access for Nutanix, OVA, QEMU and raw providers. For those providers, a resulting image is affected if an attacker reached the build VM and modified the image while construction was underway. These conditions should not be collapsed into a claim that every Image Builder output has a persistent default login.

I think of Kubernetes as a framework for reconciling declared state, but that framework assumes its nodes are a suitable execution environment. A successful reconciliation cannot establish the provenance of the machine image underneath it. This advisory concerns that earlier stage of the system, before an ordinary workload declaration can say anything useful about the node's build credentials.

The affected version is the image-building tool

The advisory identifies Image Builder v0.1.37 and earlier as affected and v0.1.38 or later as fixed. These are Image Builder versions, not Kubernetes control-plane versions. Determining exposure therefore requires knowing how the node image was produced. The Kubernetes release installed inside the VM is insufficient to answer that question.

Provider selection is equally important. The project confirms the persistent credential vulnerability for images built with Proxmox. It explicitly says images built with other providers are not affected by that particular issue. The related build-time issue has its own provider list and conditions. A fleet containing several image families may consequently have different exposure even when the nodes run the same Kubernetes release.

The project's detailed Proxmox issue states that clusters are affected only when their nodes use VM images created through Image Builder with that provider. This confines the claim to a particular construction path. Proxmox itself, every Proxmox VM and every Kubernetes installation are not interchangeable descriptions of the vulnerable population.

The announcement offers ways to identify the builder version from a source checkout, downloaded release or container image. The reason those alternatives matter is that the builder may no longer be running when the vulnerable node exists. Its version is an attribute of the process that produced the artifact, not necessarily a package available for inspection on the deployed machine.

Construction access needs a bounded lifetime

The detailed issue explains the repair as two changes. The fixed builder generates a random password for use during construction, and disables the builder account at the end. Each change addresses a different period in the image's lifetime. Randomizing the temporary password reduces exposure while the VM is being built. Disabling the account prevents that construction identity from remaining usable through the finished image.

The Proxmox cleanup patch adds a final shell provisioner to the Packer configuration. That provisioner locks the configured SSH user and shuts down the VM. It also expects the SSH connection to disconnect. This places cleanup inside the image-building sequence, where the tooling knows which construction identity it created.

The sequencing is significant. A builder needs enough access to install and configure the operating system. Its resulting node does not need to retain the same access arrangement for that earlier task. Cleanup explicitly ends that identity's usable lifetime before the image is treated as finished. The expected disconnect expresses the operational consequence of shutting down the construction VM.

That repair also shows why changing a password in a template is an incomplete description of the issue. A unique build credential and an inactive finished-image account are separate properties. One protects a temporary environment from a known shared credential. The other removes the construction identity from the normal access arrangements of machines created later.

The two CVEs have different attack conditions

For Proxmox, the advisory rates CVE-2024-9486 Critical at 9.8. Its vector describes network access with no prior privileges or user interaction. The persistent default credentials make the deployed image the relevant target. This is why the announcement tells operators to consider existing VMs using affected images, not only future builds.

For the Nutanix, OVA, QEMU and raw providers, the related issue is rated Medium at 6.3. The announcement describes exposure during the build and requires an attacker to reach and alter the VM while that build is taking place. A finished image's risk depends on whether that earlier modification occurred. This distinction is temporal as well as provider-specific.

That difference affects incident reasoning. Evidence that a build ran on an affected tool version identifies an exposure condition. For the build-time case, it does not by itself establish that the finished image contains attacker changes. Conversely, ending the vulnerable build does not undo a modification an attacker already made to the artifact. The artifact's later use can preserve the consequences of an earlier compromise.

I find this separation essential when evaluating image pipelines. Access restrictions around a temporary builder are part of the trust placed in the output. A machine image can outlive both the build VM and the credential used to configure it. Its trust depends on what could happen during construction as well as what accounts remain enabled afterward.

Repairing the tool does not replace its output

The project's prescribed remediation is to rebuild affected images with a fixed Image Builder version and redeploy those images to affected VMs. Updating the tool alone changes future construction. It does not modify an image already stored or a node already created from it. The remediation explicitly follows the defect through the artifact into the running environment.

This is an important distinction for systems managed through declarative configuration. A desired machine configuration can continue referring to an old image even after the build environment receives a fix. Unless the repaired artifact replaces that reference and reaches the affected machines, the running state may retain the original exposure. The advisory's rebuild-and-redeploy requirement identifies both parts of the repair.

The same reasoning applies to image reuse. A corrected builder does not make earlier copies safe merely because they share a recognizable image name. The relevant property is whether the image was rebuilt through the corrected construction path. A deployment needs to refer to that output for the node to receive the repaired account state.

Before an upgrade, the advisory offers disabling the builder account on affected VMs as a mitigation. It also identifies last builder as a way to inspect recorded logins to that account. These are narrow measures described by the project. A login record can be useful evidence of account use, while its absence should not be expanded into a claim that an entire image's construction was trustworthy.

The node image is part of the cluster boundary

The cleanup patch invokes its shell provisioner with a Bash shebang using error-exit behavior. Within the command, account locking and shutdown are joined so shutdown follows successful locking. These details make account cleanup part of the operation's success conditions. They are useful when examining an image-building pipeline because reaching the end of provisioning should mean that the temporary account has passed through its intended cleanup step.

The patch uses the configured SSH username rather than treating an account name in prose as the implementation. That ties the cleanup action to the identity used by the builder configuration. The advisory names the builder account for mitigation and detection, while the source shows how the construction sequence selects its cleanup target.

The disclosure makes the image pipeline an explicit part of Kubernetes security. The affected code sits in a tool used to build machines, yet the resulting access can reach the nodes running workloads. A cluster version inventory that excludes image provenance omits the component whose behavior caused this exposure.

The two-part fix aligns the construction identity with its intended lifetime. A temporary password belongs to the build, and the account is disabled when construction ends. Existing deployments still require the separate artifact replacement described by the advisory. That is the remaining operational obligation after installing the fixed builder, the machines using its older output must receive an image produced with the corrected behavior.