BuildKit Build-Time Container Teardown Arbitrary File Del...

CVE-2024-23652 is a high-severity vulnerability in BuildKit, the build engine that powers docker build, Docker Buildx, and a wide range of downstream tools (containerd, nerdctl, img, and various CI/CD image-builder integrations). The flaw lives in how BuildKit tears down the ephemeral containers it spins up while executing RUN instructions and mount directives during a build. A maliciously crafted Dockerfile or BuildKit frontend can trick the daemon into deleting files and directories on the host filesystem that fall well outside the intended build context — including, in the worst case, arbitrary paths the BuildKit daemon process has permission to remove. Because BuildKit typically runs with elevated (often root-equivalent) privileges on the build host, successful exploitation can mean anything from a broken CI runner to a full denial-of-service against a shared build fleet.

This post breaks down what CVE-2024-23652 actually does, which versions and components are affected, how it was disclosed, and what teams building container images should do about it today.

What CVE-2024-23652 Actually Does

BuildKit executes each RUN step — and mount operations like RUN --mount=type=bind or type=cache — inside a short-lived container. When that step finishes, BuildKit tears the container down and cleans up its mounts. The vulnerability tracked as CVE-2024-23652, publicly documented as "BuildKit: Build-time container teardown arbitrary file delete," arises because that teardown path does not sufficiently validate the mount source before removing it. By controlling what a mount point resolves to — for example, by swapping a directory for a symlink between setup and teardown, or crafting mount configurations through a custom frontend — an attacker-supplied Dockerfile can cause BuildKit's cleanup logic to follow that mount to a location it never should have touched, and delete it.

In practical terms, this means anyone who can get a BuildKit-based builder to process an untrusted Dockerfile — a public CI system that builds pull-request branches, a hosted "build my Dockerfile" service, a shared internal build cluster — can potentially cause the daemon to delete files anywhere on the underlying host that the daemon's own privileges allow. That includes the possibility of destroying other tenants' build caches, corrupting the container runtime's own state, or removing arbitrary system files to force a denial-of-service condition.

This vulnerability was disclosed alongside three related BuildKit issues from the same research effort: an information-disclosure bug in cache mount handling (CVE-2024-23651), a gRPC SecurityMode bypass affecting BuildKit's exposed API (CVE-2024-23653), and a null-pointer denial-of-service in the Dockerfile frontend (CVE-2024-23650). CVE-2024-23652 is the one specifically concerned with arbitrary file deletion via build teardown, and of the four it is one of the more operationally dangerous, since it doesn't require an attacker to already have API access — a malicious Dockerfile is enough.

Affected Versions and Components

• BuildKit (moby/buildkit) prior to v0.12.5 is affected. BuildKit is the default build backend for docker build on modern Docker installations with BuildKit enabled, and it is the engine behind Docker Buildx, Docker's CLI plugin for extended, multi-platform builds.
• Docker Engine and Docker Desktop releases that bundle a vulnerable BuildKit version inherit the flaw. Docker shipped patched engine and desktop builds incorporating BuildKit v0.12.5 in the days following disclosure.
• Any downstream project or CI/CD platform that vendors BuildKit as a library — including tools built on buildctl, Kubernetes-native image builders, and third-party build-as-a-service offerings — is potentially exposed until it pulls in the fixed release.

If your organization builds container images anywhere — local developer machines, self-hosted runners, managed CI, or a platform team's internal build service — it's worth explicitly confirming the BuildKit version in use rather than assuming a routine Docker update already covered it.

CVSS, EPSS, and KEV Context

CVE-2024-23652 was rated High severity, with a CVSS v3.1 base score in the 8.7 range, reflecting a build workflow that's reachable without special privileges, low attack complexity, and high impact to integrity and availability (arbitrary deletion of host files) with no direct confidentiality impact. That places it in the same severity band as its sibling BuildKit advisories from the same disclosure batch.

As of this writing, CVE-2024-23652 does not appear on CISA's Known Exploited Vulnerabilities (KEV) catalog, and its EPSS (Exploit Prediction Scoring System) probability remains low, consistent with no confirmed evidence of in-the-wild exploitation. That said, EPSS and KEV status reflect observed exploitation activity, not exploitability — the technical bar to weaponize this bug against an untrusted-Dockerfile build pipeline is not high, and build systems that accept external contributions (fork-based PR builds, public Dockerfile submission services) should treat it as a real, current risk rather than a historical footnote.

Timeline

• Disclosure: CVE-2024-23652 was published in late January 2024 alongside three related BuildKit advisories (CVE-2024-23650, CVE-2024-23651, CVE-2024-23653), all addressing distinct weaknesses in BuildKit's build-container lifecycle and frontend handling.
• Fix: The BuildKit maintainers shipped the fix in BuildKit v0.12.5, hardening the teardown path so mount sources are re-validated rather than blindly followed at cleanup time.
• Downstream patching: Docker followed with updated Docker Engine and Docker Desktop releases that pull in the patched BuildKit, and other projects that embed BuildKit — container build services, alternative CLIs, CI image-builder actions — issued their own follow-up updates over the following weeks.

Remediation Steps

1. Upgrade BuildKit to v0.12.5 or later. This is the authoritative fix. If you invoke BuildKit directly (via buildctl, a custom frontend, or as an embedded library), confirm the vendored version explicitly rather than relying on transitive dependency updates.
2. Update Docker Engine and Docker Desktop to a release that bundles the patched BuildKit. Check docker buildx version and docker version output against your vendor's advisory to confirm.
3. Patch or pin build tooling that embeds BuildKit, including CI/CD image-builder actions, Kubernetes-native build tools, and any internal "build service" that runs untrusted Dockerfiles on shared infrastructure.
4. Treat untrusted Dockerfiles as untrusted code. Until patched, avoid running docker build or Buildx against Dockerfiles or custom frontends from unverified sources — this is good practice generally, but it's the direct mitigating control for this class of build-teardown bug.
5. Isolate build workers. Run builds in ephemeral, single-use environments (a fresh VM or container per build) so a successful arbitrary file deletion has no persistent host state to damage and can't affect other tenants' builds.
6. Reduce daemon privilege where possible. Rootless BuildKit and Docker configurations shrink the blast radius of any teardown-time file deletion, since the daemon simply lacks permission to touch most of the host filesystem.
7. Monitor build infrastructure for anomalous deletions — unexpected removal of files outside the workspace, sudden loss of cache volumes, or build-container teardown errors — as a possible indicator of attempted exploitation.

How Safeguard Helps

Vulnerabilities like CVE-2024-23652 sit exactly at the seam Safeguard is built to watch: the software supply chain infrastructure that produces your artifacts, not just the artifacts themselves. Safeguard continuously inventories the build tooling across your CI/CD estate — including BuildKit, Docker Buildx, and every container build backend in use — and maps each instance to the CVEs that actually apply to its deployed version, so a bug like an arbitrary file deletion during build teardown doesn't quietly sit unpatched on a self-hosted runner for months.

Beyond detection, Safeguard's policy engine can flag and block build pipelines that run untrusted Dockerfiles against unpatched BuildKit versions, enforce ephemeral, isolated build environments as a baseline control, and alert your team the moment a new advisory affecting your build stack is published — turning "we should probably check our BuildKit version" into an automated, continuously enforced guardrail. For security and platform teams managing fleets of build runners, that means CVEs like this one get triaged and remediated on the order of hours, not discovered months later during an audit.