CVE-2026-33747

What it actually does

CVE-2026-33747 is a path traversal / arbitrary file write flaw in BuildKit before 0.28.1. When a build uses an untrusted custom BuildKit frontend supplied through a Dockerfile `#syntax` directive or `--build-arg BUILDKIT_SYNTAX`, that frontend can craft BuildKit API messages that cause files to be written outside the intended BuildKit execution state directory. Depending on the privileges of the BuildKit daemon or worker, this can allow modification or destruction of host files, tampering with build outputs, exposure of sensitive files, and in some environments a path to code execution or persistence by overwriting scripts, configuration, credentials, or build infrastructure files.

Why it matters to the business

Organizations that allow developers, external contributors, or automated pipelines to build untrusted repositories with BuildKit may face compromise of CI/CD workers, tampered build artifacts, credential exposure, or disruption of build services. The main operational risk is supply-chain impact: a malicious repository or build definition could alter the build environment and affect downstream artifacts. Current public exploit maturity is listed as none, EPSS is low and stable at about 0.005, and the issue is not in CISA KEV or known ransomware use, but the CVSS score is high because successful exploitation can affect confidentiality, integrity, and availability of the build host.

How an attack unfolds

An attacker needs a build process that uses a vulnerable BuildKit version and accepts an untrusted custom frontend. The attacker prepares a repository, Dockerfile, or build command that references a malicious frontend using `#syntax` or `--build-arg BUILDKIT_SYNTAX`. When the vulnerable builder resolves and executes that frontend, the frontend sends a crafted API message to BuildKit. Instead of constraining file writes to the expected BuildKit state directory for the execution context, vulnerable BuildKit writes attacker-controlled content outside that directory. The attacker can then target sensitive or operationally important paths available to the BuildKit process, potentially corrupting the worker, planting files for later execution, modifying build behavior, or interfering with artifact integrity. Use of well-known trusted frontends such as `docker/dockerfile` is not affected by this specific issue.

How to fix it

Upgrade BuildKit to version 0.28.1 or later. If BuildKit is delivered through Docker Engine, Docker Buildx, a CI runner image, Kubernetes build worker, or another packaged toolchain, update the containing package or image to one that embeds a fixed BuildKit release. As immediate mitigation, do not allow untrusted projects to select arbitrary BuildKit frontends through `#syntax` or `--build-arg BUILDKIT_SYNTAX`; enforce an allowlist of trusted, pinned frontend images such as known-good `docker/dockerfile` versions. Run build workers as isolated, disposable, least-privileged environments, preferably rootless where operationally feasible. Avoid sharing sensitive host paths or long-lived credentials with build workers, and rebuild or rotate potentially exposed CI workers and secrets if suspicious untrusted frontend use is found.

How to confirm the fix worked

Confirm the installed BuildKit version is 0.28.1 or newer using `buildkitd --version`, `buildctl --version`, Docker Buildx version checks, package manager inventory, or CI runner image manifests. Review Dockerfiles and build definitions for custom `#syntax` values and build commands for `--build-arg BUILDKIT_SYNTAX`; verify that only approved, pinned frontend images are allowed. Confirm CI/CD policy prevents arbitrary frontend selection from untrusted repositories or pull requests. Where possible, run a controlled negative test with an untrusted frontend in a non-production lab to verify that file writes are constrained and that updated builders reject or safely handle malicious frontend behavior. Validate that all build worker images, autoscaling templates, and cached runner images have been refreshed after upgrading.

Typical attack path

1. Identify a CI/CD, developer workstation, or build service running BuildKit before 0.28.1.
2. Get an untrusted build definition accepted by the build system, such as through a repository, pull request, dependency build, or manually supplied build command.
3. Specify a malicious custom BuildKit frontend using a Dockerfile `#syntax` directive or `--build-arg BUILDKIT_SYNTAX`.
4. Have the vulnerable build process pull and execute the attacker-controlled frontend.
5. Send crafted BuildKit API messages from the frontend that trigger writes outside the intended BuildKit state directory.
6. Overwrite or create files accessible to the BuildKit daemon or worker user.
7. Use the file write to tamper with builds, disrupt the worker, expose data, or establish a follow-on execution path depending on host permissions and file targets.

How to detect it

To assess prior exploitation, review CI/CD job logs, build service logs, BuildKit daemon logs, source repository history, and build command audit records for use of untrusted custom frontends via `#syntax` or `--build-arg BUILDKIT_SYNTAX`. Focus on builds run by BuildKit versions before 0.28.1, especially those triggered by external contributors, pull requests, imported repositories, or third-party build definitions. Look for frontend images outside the organization’s approved registry or allowlist, recently introduced Dockerfile syntax directives, unexpected pulls of unfamiliar frontend images, and build failures or warnings around filesystem operations. On build workers, inspect file modification timelines for unexpected writes outside BuildKit state directories during build windows, especially changes to shell profiles, service units, cron paths, CI runner configuration, credential locations, SSH authorized keys, build scripts, and artifact staging paths. Compare worker filesystem baselines before and after suspicious builds where possible. Because the advisory does not provide a unique exploit payload, detection should combine version exposure, untrusted frontend usage, unexpected filesystem writes, anomalous child processes, and credential access around the same build execution window.

• #syntax=
• BUILDKIT_SYNTAX
• --build-arg BUILDKIT_SYNTAX
• buildkitd
• buildctl
• docker/dockerfile

What your security team should do

• Inventory all BuildKit deployments, including standalone buildkitd, Docker Buildx builders, CI runner images, Kubernetes build workers, and developer workstation builder images.
• Upgrade BuildKit to 0.28.1 or later everywhere it is used.
• Prioritize shared CI/CD builders and systems that build untrusted repositories, pull requests, third-party code, or externally supplied Dockerfiles.
• Block or restrict arbitrary `#syntax` and `BUILDKIT_SYNTAX` usage; allow only approved, pinned frontend images from trusted registries.
• Treat build workers that processed untrusted custom frontends before patching as potentially compromised; inspect, rebuild, or rotate them based on exposure.
• Rotate credentials available to affected build environments if logs show untrusted frontend execution or unexpected filesystem modification.
• Add CI policy checks that fail builds using unauthorized BuildKit frontends.
• Prefer ephemeral, rootless, least-privileged build workers with no sensitive host mounts.
• Monitor build logs and source repositories for newly introduced custom frontend directives.
• Track vendor updates for Docker, Buildx, CI runner images, and distribution packages that bundle BuildKit.