BuildKit Mount Cache Race Condition Vulnerability (CVE-20...

CVE-2024-23651 is a high-severity race condition vulnerability in BuildKit, the build engine behind docker build, Docker Buildx, and much of the modern container image supply chain. Disclosed on January 31, 2024, the flaw allows two malicious build steps running in parallel to exploit a time-of-check/time-of-use gap in how BuildKit mounts cache volumes with subpaths — potentially exposing files from the host system to the build container. For any organization building container images in shared or multi-tenant CI infrastructure, this is exactly the kind of bug that turns "just another Dockerfile" into a path off the build node.

BuildKit's cache mounts (RUN --mount=type=cache,...) exist to make builds faster by persisting package manager caches, compiler output, and other artifacts between build runs. CVE-2024-23651 abuses the machinery that sets these mounts up. It was one of four related BuildKit/Moby findings — alongside CVE-2024-23650, CVE-2024-23652, and CVE-2024-23653 — published together with a companion runc vulnerability (CVE-2024-21626) under the collective research name "Leaky Vessels." Below, we break down what the vulnerability actually does, who it affects, how serious it is by the numbers, and what to do about it.

What Is CVE-2024-23651?

At its core, CVE-2024-23651 is a race condition (CWE-362) in how BuildKit prepares cache mount subpaths for a build step. When a Dockerfile (or a malicious BuildKit frontend) defines two build steps that run concurrently and share the same cache mount with overlapping subpaths, an attacker can win a timing window between when BuildKit validates a mount path and when it actually binds that path into the build container.

By racing that window, a build step can cause BuildKit to resolve a cache subpath to a location it should never be able to reach — including paths on the underlying host filesystem rather than the isolated cache volume. The practical effect is that a build process that should be sandboxed inside its own container gets a view into files it has no business seeing, undermining the isolation guarantee that docker build and Docker Buildx are supposed to provide between the build sandbox and the host running the daemon.

This matters because container builds are, by design, meant to execute untrusted or semi-trusted instructions — arbitrary RUN commands from a Dockerfile someone else wrote, a base image pulled from a public registry, or a custom BuildKit frontend. The entire security model of that arrangement depends on BuildKit's mount handling holding the line between "inside the build container" and "the host." A race condition in that handling is a direct hit against the isolation boundary the supply chain relies on.

Affected Versions and Components

CVE-2024-23651 affects BuildKit versions through v0.12.4. The fix landed in BuildKit v0.12.5. Because BuildKit is embedded in — rather than separate from — most of the modern Docker toolchain, the blast radius extends well past people who manually run buildkitd:

• Docker Engine — BuildKit has been the default build backend since Docker Engine 23.0, so any engine bundling a pre-0.12.5 BuildKit is exposed. Docker shipped BuildKit v0.12.5 as part of the Docker Engine 25.0.2 release.
• Docker Buildx — the docker buildx CLI plugin and docker/setup-buildx-action used heavily in GitHub Actions and other CI pipelines drive BuildKit directly, so pipelines pinned to an older Buildx/BuildKit combination remain vulnerable until updated.
• Docker Desktop — received an updated build following the January 31 disclosure to pull in the patched BuildKit.
• Standalone buildkitd deployments — teams running BuildKit as a remote builder (e.g., behind buildctl, in Kubernetes via buildkit pods, or as part of custom CI build farms) needed to upgrade the daemon independently of any Docker Engine update.
• containerd-based builders and any tool that vendors BuildKit as a library are also affected if they haven't picked up the v0.12.5 fix.

In short: if your build cache mount usage runs on a BuildKit engine older than v0.12.5, whether that's reached through docker build, Docker Buildx, a CI action, or a self-managed buildkitd, you're exposed.

CVSS, EPSS, and KEV Context

Severity scoring for CVE-2024-23651 differs slightly depending on the source, which is itself informative about how the bug is being interpreted:

• NVD rates it 7.4 (High) under CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N.
• GitHub's advisory (CNA) scoring rates it higher, at 8.7 (High), under CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N — the key difference being a Scope: Changed designation, reflecting that a successful exploit lets the build container reach beyond its own security boundary into the host.

Both scorings agree on the shape of the risk: no privileges or user interaction required, high complexity to actually win the race, and high confidentiality and integrity impact once it lands. That "high attack complexity" (AC:H) is a meaningful caveat — this isn't a trivial one-shot exploit, since it depends on successfully racing concurrent build steps against BuildKit's internal mount setup.

That complexity shows up in the exploitation data, too. As of this writing, the EPSS score for CVE-2024-23651 is roughly 0.8%, sitting around the 52nd percentile of all scored CVEs — indicating a low observed likelihood of exploitation in the wild relative to the broader vulnerability population. It has not been added to CISA's Known Exploited Vulnerabilities (KEV) catalog. In other words, this is a serious design-level flaw in a widely used piece of build infrastructure, but the available signals suggest it has not become a common ingredient in real-world attack chains, at least not yet. That should not be read as a reason to deprioritize patching — build infrastructure compromises are exactly the kind of low-noise, high-value target that doesn't need to be mass-exploited to be damaging.

Timeline

• Vulnerability identified by Rory McNamara of Snyk's research team, as part of a broader review of build-time container isolation that also produced the companion runc finding, CVE-2024-21626.
• January 31, 2024 — Coordinated disclosure. BuildKit v0.12.5 was released with the fix, GitHub published the security advisory (GHSA-m3r6-h7wv-7xxv) with CVE-2024-23651 assigned, and Docker published a security advisory covering CVE-2024-23651 alongside the related BuildKit issues CVE-2024-23650 (denial of service via nil pointer dereference), CVE-2024-23652 (host file/directory removal via the mount stub cleaner), and CVE-2024-23653 (privileged command execution via a GRPC frontend confused-deputy issue), as well as runc's CVE-2024-21626. Docker Engine 25.0.2 shipped the same day with the patched BuildKit bundled in.
• February 1, 2024 — Docker Desktop received an updated release incorporating the fixed components.
• Downstream Linux distributions and container base image maintainers followed with their own package updates over the following days and weeks as they rebuilt against the patched BuildKit release.

Remediation Steps

1. Upgrade BuildKit to v0.12.5 or later. This is the actual fix; everything else is a mitigating control until this happens.
2. Update Docker Engine to 25.0.2 or later (or the equivalent patched release for your Docker Engine line), which bundles the fixed BuildKit.
3. Update Docker Buildx and CI build actions. Bump docker/setup-buildx-action, docker/buildx, and any pinned BuildKit container images used as remote builders in your pipelines.
4. Patch standalone buildkitd deployments independently if you run BuildKit as a remote builder or inside Kubernetes — these do not get patched automatically by an engine or CLI upgrade.
5. Audit build cache mount usage. Identify Dockerfiles and BuildKit frontends using RUN --mount=type=cache with subpaths, particularly in pipelines that build multiple images or run multiple concurrent build steps against shared cache state.
6. Avoid untrusted BuildKit frontends and Dockerfiles until patched. As an interim mitigation, don't build Dockerfiles or use custom frontends from sources you don't fully trust, and be cautious with multi-stage builds that parallelize steps sharing cache mounts.
7. Verify the fix took effect with docker buildx version or buildctl --version against your build hosts and CI runners, and confirm base images used as build environments have been rebuilt against patched BuildKit.
8. Re-check container build isolation assumptions generally. CVE-2024-23651 is a reminder that build-time containers are not the same trust boundary as runtime containers — treat build infrastructure with the same rigor as production infrastructure.

How Safeguard Helps

CVE-2024-23651 is a textbook example of a software supply chain risk that lives outside your application dependency tree entirely — it's in the build tooling itself, the layer most teams assume is "just infrastructure" and rarely inventory with the same discipline as application libraries. Safeguard is built to close exactly that gap.

Safeguard continuously inventories the components of your build and CI/CD environment — BuildKit versions, Docker Buildx and Engine releases, base images used as builders, and the actions and plugins wired into your pipelines — so that a vulnerability like CVE-2024-23651 shows up as an actionable finding tied to specific runners and pipelines, not a line item in a generic advisory feed. When a new BuildKit or Docker Buildx CVE is published, Safeguard maps it against your actual build fleet, flags which pipelines are still running vulnerable versions, and prioritizes remediation using real severity and exploitability context — CVSS, EPSS, and KEV status — rather than raw CVSS alone.

Because this class of bug specifically targets the trust boundary between build-time containers and the host, Safeguard's supply chain monitoring also helps enforce guardrails around what gets built where: flagging untrusted Dockerfiles, frontends, and cache mount patterns that echo the exact conditions CVE-2024-23651 exploited, and giving security teams visibility into build infrastructure drift before it becomes an incident. The goal is straightforward — make sure the tools that build your software are held to the same security bar as the software they produce.

Sources: GitHub Advisory GHSA-m3r6-h7wv-7xxv, NVD CVE-2024-23651, Docker Security Advisory: Multiple Vulnerabilities in runc, BuildKit, and Moby, Snyk Labs: CVE-2024-23651 BuildKit Mount Cache Race.