CVE-2024-23651

What it actually does

Race condition in BuildKit allows two parallel malicious build steps sharing cache mounts with subpaths to expose host system files to the build container.

Why it matters to the business

Unpatched build systems risk unauthorized access to host files during container builds, potentially exposing source code or secrets in CI/CD pipelines; with the issue public for over two years and a modest EPSS rise, delayed upgrades increase ongoing exposure across dependent projects.

How an attack unfolds

An attacker supplies an untrusted Dockerfile or frontend containing parallel build steps that declare cache mounts with subpaths; the race condition during concurrent execution leaks host filesystem contents into the container context.

How to fix it

Upgrade moby/buildkit to the fixed commit bac3f2b673f3f9d33e79046008e7a38e856b3dc6 (v0.12.5 or later); avoid untrusted frontends and cache mounts in untrusted Dockerfiles until upgraded.

How to confirm the fix worked

Verify BuildKit version is at or above the fixed commit; scan Dockerfiles and build configurations for cache mount usage and confirm no untrusted sources are permitted.

Typical attack path

1. Supply malicious Dockerfile or frontend using --mount=type=cache,source=... options in parallel steps
2. Trigger concurrent builds that share the same cache mount paths
3. Exploit timing window to read host files into the build container
4. Exfiltrate leaked data or use it for further container compromise

How to detect it

Review build logs and Dockerfile histories for parallel cache mount declarations from untrusted sources; examine container runtime traces for unexpected host file accesses during builds.

What your security team should do

• Immediately upgrade all BuildKit instances to the fixed commit bac3f2b673f3f9d33e79046008e7a38e856b3dc6
• Audit build pipelines to restrict cache mounts and untrusted frontends
• Monitor EPSS trend and re-evaluate if new exploit code appears