CVE-2026-15789: BuildKit Auth Bypass Vulnerability

CVE-2026-15789 Overview

CVE-2026-15789 is a path traversal vulnerability [CWE-22] affecting the Moby BuildKit daemon. A custom client can craft an upload request that causes files to escape the BuildKit-controlled state directory. Successful exploitation requires the client to already hold valid permissions to access the BuildKit control API and issue builds. The vulnerability enables an authenticated local actor to write files outside the intended sandbox boundary, impacting integrity and availability of the host filesystem.

Critical Impact
An authenticated client can write arbitrary files outside the BuildKit state directory, enabling tampering with host files, build artifacts, or daemon configuration.

Affected Products

Moby BuildKit daemon (buildkitd)
Container build tooling that embeds BuildKit
Environments exposing the BuildKit control API to multiple tenants

Discovery Timeline

2026-07-21 - CVE-2026-15789 published to NVD
2026-07-21 - Last updated in NVD database

Technical Details for CVE-2026-15789

Vulnerability Analysis

BuildKit exposes a control API that accepts upload requests carrying files the daemon writes into its state directory. The daemon fails to fully sanitize file paths supplied in these upload requests. A custom client, bypassing the standard buildctl or Docker CLI helpers, can embed traversal sequences such as ../ in the target path. The daemon resolves those sequences during write, placing files outside the intended state directory root.

Because buildkitd frequently runs with elevated privileges to manage snapshots, cache, and OCI layers, escaping the state directory allows the attacker to write into paths owned by the daemon user. This can overwrite build cache metadata, drop binaries into executable search paths, or corrupt other tenants' build state on shared hosts.

Root Cause

The root cause is improper limitation of a pathname to a restricted directory [CWE-22]. The upload handler trusts client-supplied filenames and joins them to the state directory without canonicalizing the resulting path or rejecting traversal components. There is no post-join check that the resolved path remains within the intended root.

Attack Vector

The attack vector is local. An adversary must already authenticate to the BuildKit control API — for example, via a Unix socket, TCP endpoint, or after bypassing an upstream authentication layer. Once connected, the adversary sends a custom-crafted upload request that references a path containing traversal sequences. The daemon writes the client-supplied bytes to the resolved location, producing arbitrary file write with the privileges of buildkitd.

No verified public exploit code is available. Refer to the GitHub Security Advisory GHSA-g2h8-426c-7976 for authoritative technical details.

Detection Methods for CVE-2026-15789

Indicators of Compromise

Files appearing outside the BuildKit state directory (default /var/lib/buildkit) with buildkitd as the owning process.
Unexpected modifications to system binaries, cron directories, or shell profile files coinciding with active build sessions.
BuildKit daemon log entries showing upload requests with filenames containing .., absolute paths, or unusual separators.

Detection Strategies

Enable audit logging on the BuildKit host and monitor open/openat syscalls issued by buildkitd for write targets outside its state directory.
Correlate BuildKit control API sessions with filesystem write events to identify writes that fall outside expected build contexts.
Alert on non-standard clients — connections to the control API that do not originate from buildctl or an authorized CI runner.

Monitoring Recommendations

Track integrity of directories writable by the buildkitd service account using file integrity monitoring.
Monitor for privilege escalation patterns such as new SUID files or modified authorized_keys on hosts running buildkitd.
Retain BuildKit daemon logs centrally and review requests containing suspicious path components.

How to Mitigate CVE-2026-15789

Immediate Actions Required

Restrict access to the BuildKit control API to trusted users and CI systems only.
Do not expose buildkitd over TCP without mutual TLS and strict client authentication.
Run buildkitd in rootless mode where feasible to reduce the blast radius of an arbitrary file write.
Audit existing BuildKit hosts for files owned by the daemon that reside outside the state directory.

Patch Information

Apply the fixed version referenced in the upstream Moby BuildKit Security Advisory GHSA-g2h8-426c-7976. Rebuild and redeploy any container images or CI runners that embed a vulnerable buildkitd binary.

Workarounds

Isolate buildkitd per tenant so that a compromised client cannot affect unrelated build state.
Confine the daemon with mandatory access control (SELinux, AppArmor) restricting writes to the state directory only.
Place buildkitd inside a dedicated user namespace or container with a read-only host filesystem outside /var/lib/buildkit.

bash

# Example AppArmor snippet restricting buildkitd writes to its state directory
/var/lib/buildkit/** rw,
deny /** w,