BuildKit Privileged Entitlement Check Bypass Enabling Hos...

In January 2024, the maintainers of Moby/BuildKit disclosed a vulnerability that struck at the heart of container build infrastructure: CVE-2024-23653, a privileged entitlement check bypass in BuildKit's interactive containers API that lets a malicious or compromised Dockerfile escape the build sandbox and obtain root-level access to the underlying host — even when the build was never granted elevated permissions in the first place. For any organization running docker build, docker buildx, or a CI pipeline that builds container images from untrusted or third-party Dockerfiles, CVE-2024-23653 is a reminder that the build stage is just as much an attack surface as production runtime.

What CVE-2024-23653 actually is

BuildKit is the modern build engine behind Docker Buildx and the default builder in current Docker Engine and Docker Desktop releases. It ships an entitlements model that is supposed to gate risky capabilities — most notably security.insecure, which allows a build step to run in a privileged container. Builds must explicitly request this entitlement, and the daemon or orchestrator must explicitly grant it, before a RUN --security=insecure instruction is allowed to execute with elevated capabilities.

The flaw behind CVE-2024-23653 lives in BuildKit's interactive containers (debugging) API — the mechanism used by features like buildctl debug and docker buildx debug-shell to attach an interactive process to a running build container. BuildKit failed to enforce the same entitlement check on containers spawned through this debugging interface that it enforces on regular build steps. As a result, a Dockerfile author (or an attacker who can influence Dockerfile content, a build context, or a base image with build-time logic) could invoke the interactive containers path and end up with a privileged container, bypassing the security.insecure gate entirely — without the build ever having been granted that entitlement.

The practical impact is a full container escape: a process that should be confined to an unprivileged build container instead runs with host-level privileges, giving an attacker the ability to read and write arbitrary files on the host, tamper with other containers, or pivot further into the build infrastructure. Because this occurs during build-time privilege negotiation rather than at container runtime, it is easy for security teams focused on runtime hardening to miss entirely — the exposure exists in CI runners, developer laptops, and any service that builds images on demand.

Affected versions and components

CVE-2024-23653 affects BuildKit prior to v0.12.5. Because BuildKit is embedded in several downstream tools, the practical blast radius includes:

• Docker Buildx — the CLI plugin that drives BuildKit-based builds and was distributed with the vulnerable BuildKit versions bundled in.
• Docker Engine and Docker Desktop — releases that shipped an unpatched BuildKit as their default builder were affected until they picked up the fix (Docker's advisories point to Docker Engine 25.0.2 and 24.0.9 as the first versions carrying the patched component).
• Any custom build pipeline or CI runner that invokes buildctl/BuildKit directly, including Kubernetes-based build services (e.g., BuildKit-as-a-service deployments) using an affected version.

The vulnerability was tracked upstream via a GitHub Security Advisory in the moby/buildkit repository alongside a cluster of other BuildKit issues disclosed in the same window (cache-related race conditions and a build-time container teardown flaw), which is worth knowing if you're triaging a Dependabot or Trivy report that surfaces several BuildKit CVEs at once from the same remediation.

CVSS, EPSS, and KEV context

The GitHub Security Advisory for CVE-2024-23653 rates it High severity, with NVD scoring it around 8.5 on the CVSS v3.1 scale, reflecting network-adjacent exploitability with no privileges or user interaction required once an attacker can supply or influence the Dockerfile/build request, combined with a high confidentiality and integrity impact from the resulting host compromise. As of this writing, CVE-2024-23653 does not appear on CISA's Known Exploited Vulnerabilities (KEV) catalog, and public EPSS scoring has remained low — consistent with a vulnerability that requires an attacker to control build input rather than being remotely triggerable against a passive target. That combination — high severity, low observed exploitation — is exactly the profile that tends to get deprioritized by teams that scan for KEV-listed or high-EPSS issues only, which is a risky filter to apply to software supply chain findings.

It's worth being precise about the threat model: CVE-2024-23653 is not a vulnerability an internet-facing attacker can trigger without help. It requires the ability to get a target BuildKit instance to build a malicious Dockerfile or build definition — a bar that is trivially met in several common scenarios: public CI systems that build pull requests from forks, internal "build-as-a-service" platforms that accept Dockerfiles from many teams, and any pipeline that pulls third-party base images or build contexts without verification.

Timeline

• Prior to January 2024 — The entitlement check gap exists in BuildKit's interactive containers API across multiple release lines.
• January 2024 — Moby/BuildKit maintainers disclose CVE-2024-23653 via a GitHub Security Advisory, alongside related BuildKit advisories covering cache race conditions and build container teardown issues, and ship BuildKit v0.12.5 with the fix.
• Late January 2024 — Docker publishes corresponding advisories and ships patched Docker Engine and Docker Desktop releases (Docker Engine 25.0.2 and 24.0.9) that bundle the fixed BuildKit.
• Ongoing — CVE-2024-23653 is picked up by SCA and container scanning vendors and continues to surface in dependency audits of build infrastructure, base images with bundled build tooling, and BuildKit-as-a-service deployments that haven't yet rebuilt on the patched release.

Remediation steps

1. Upgrade BuildKit to v0.12.5 or later. This is the direct fix for CVE-2024-23653. If you consume BuildKit indirectly, confirm the version pinned by your tooling rather than assuming a recent Docker install is patched.
2. Upgrade Docker Engine, Docker Desktop, and Docker Buildx to releases that bundle the patched BuildKit (Docker Engine 25.0.2 / 24.0.9 or newer). Check any pinned Buildx binary versions used in CI images separately from the host Docker install.
3. Audit standalone BuildKit deployments. Kubernetes-based build services, remote buildkitd daemons, and rootless BuildKit containers used in CI should be inventoried and patched independently of any Docker Desktop upgrade — they're easy to overlook since they don't show up in a docker version check.
4. Restrict who can submit build definitions. Since exploitation requires control over the Dockerfile or build context, tightening who can trigger builds — and never building untrusted forks with elevated CI privileges — reduces exposure while patching rolls out.
5. Avoid granting security.insecure by default, and audit any pipeline configuration that enables it broadly rather than per-build-step.
6. Run BuildKit rootless where feasible, and isolate build runners from sensitive infrastructure so that a successful container escape has a smaller blast radius even post-patch.
7. Re-scan images and build environments after patching to confirm the vulnerable BuildKit version is no longer present anywhere in the pipeline, including cached builder images and long-lived CI runner containers that may not get rebuilt automatically.

How Safeguard Helps

CVE-2024-23653 is a textbook example of why software supply chain security has to extend past the artifacts you ship and into the tooling that builds them. Safeguard is built for exactly this gap.

• Build infrastructure visibility: Safeguard continuously inventories the components in your CI/CD and build environments — including BuildKit, Docker Buildx, and the base images your builders run on — so a vulnerable version doesn't sit undetected in a runner image or a BuildKit-as-a-service deployment.
• Vulnerability and CVE correlation: When CVEs like CVE-2024-23653 are disclosed, Safeguard maps them against your actual build fleet and flags exactly which pipelines, runners, or container images need to be patched, cutting through generic advisories to give you an actionable, prioritized list.
• Policy enforcement at build time: Safeguard can enforce guardrails on entitlements such as security.insecure, alert on unusual privileged container activity during builds, and gate merges or deployments that originate from unpatched build infrastructure.
• Supply chain provenance and attestation: By tying build environment integrity into SBOM and provenance data, Safeguard helps you demonstrate — to auditors, customers, or your own security team — that the systems producing your artifacts were not running with a known container escape vulnerability like CVE-2024-23653 at build time.
• Continuous monitoring beyond patch day: Because BuildKit and Buildx versions can drift back into pipelines through pinned base images or cached runner templates, Safeguard's continuous scanning catches regressions long after the initial remediation.

Container escapes rooted in build-time privilege bugs are quietly dangerous precisely because they target infrastructure most teams treat as trusted by default. CVE-2024-23653 shows that the build step deserves the same scrutiny as production — and Safeguard is designed to make sure that scrutiny happens automatically, every time.