BuildKit patches file escape via malicious custom frontend

TL;DR — If you use #syntax / BUILDKIT_SYNTAX with an untrusted BuildKit frontend, that frontend can craft API messages that write files outside BuildKit’s state directory.

What happened

BuildKit is the build engine behind many modern container image build workflows (e.g., Docker Buildx), translating build definitions into reproducible build steps.

A GitHub-reviewed advisory for github.com/moby/buildkit (CVE-2026-33747) reports that a custom BuildKit frontend can craft an API message that causes files to be written outside of the BuildKit state directory for the execution context. The advisory characterizes this as a path traversal class issue (CWE-22) with High severity (CVSS 8.4).

This is a classic CI/CD trust-boundary failure mode: once “build definition parsing” is delegated to a third-party/frontend image, the frontend becomes part of the build system’s TCB. Platform teams should treat “custom frontend” usage as equivalent to running untrusted code inside the build control plane.

Who is impacted

• Organizations using BuildKit with custom frontends, especially when the frontend image is not fully trusted.
• Builds that set a frontend via #syntax in a Dockerfile or --build-arg BUILDKIT_SYNTAX.

What to do now

• Follow vendor remediation guidance and apply a patched release.

  "The issue has been fixed in v0.28.1+"

• Audit your build infrastructure for any use of custom frontends and explicitly identify which pipelines can set #syntax or BUILDKIT_SYNTAX.
• Treat frontend images as a supply-chain input: restrict who can change them, pin by immutable digest, and ensure only vetted frontends are allowed.
• If you cannot upgrade immediately, align with the advisory’s stated exposure constraints and avoid untrusted frontends:

  "Issue requires using an untrusted BuildKit frontend set with #syntax or --build-arg BUILDKIT_SYNTAX. Using these options with a well-known frontend image like docker/dockerfile is not affected."