CVE-2026-33748

What it actually does

BuildKit before v0.28.1 does not sufficiently validate the subdirectory component of Git URL build contexts. When a build uses a Git URL with a subpath, a malicious or untrusted repository can cause the selected subdirectory to resolve outside the checked-out repository root, for example through a crafted symlink. The practical impact is unauthorized read access to files on the same mounted filesystem that the BuildKit worker can access; the vulnerability is primarily a confidentiality issue and does not directly provide code execution, integrity modification, or denial of service by itself.

Why it matters to the business

Organizations that build container images directly from Git URLs, especially from untrusted repositories or user-controlled build inputs, could unintentionally expose source code, configuration files, cached build materials, credentials, or other sensitive files available to the BuildKit worker. Although EPSS is currently low and there is no known KEV listing or public exploit maturity reported, the issue is important in CI/CD and multi-tenant build environments because build systems often have access to secrets and proprietary code.

How an attack unfolds

An attacker first needs a build workflow that allows them to influence the Git repository URL, the Git fragment subdirectory, or the contents of the referenced repository. They create or control a Git repository containing a subdirectory path that resolves through a symlink or similar filesystem construct outside the repository checkout root. The victim BuildKit instance is then instructed to build using a Git URL with a subpath component that selects the crafted location. During context resolution, vulnerable BuildKit versions may follow or accept the path resolution and include files from outside the intended repository root, limited to the same mounted filesystem. The attacker can then cause the Dockerfile or build steps to read, copy, archive, or exfiltrate those unintended files through build output, image layers, logs, artifacts, or network egress from the build process.

How to fix it

Upgrade BuildKit to v0.28.1 or later wherever BuildKit is embedded or used directly, including standalone buildkitd deployments, Docker Buildx builders, CI runner images, container build services, and developer workstations. If immediate upgrade is not possible, do not build Dockerfiles or build contexts from untrusted Git repositories; do not allow untrusted users to control Git URL fragment subdirectory components; avoid Git URL subpaths from untrusted sources; reject repository subdirectories that are symlinks; and isolate BuildKit workers so the build mount contains only the intended checkout and no sensitive neighboring files. Review CI/CD policies to ensure secrets are not mounted into generic build contexts and are only exposed through dedicated secret mechanisms.

How to confirm the fix worked

Confirm the running BuildKit version is v0.28.1 or later by checking buildkitd, Docker Buildx builder instances, CI build images, and any embedded BuildKit distribution. Validate that build jobs using Git URLs with subpaths still succeed after upgrade and that crafted test repositories with symlinked subdirectories cannot cause files outside the repository root to appear in the build context. Search pipeline definitions, build scripts, and CI templates for Git URL contexts containing fragment subpaths such as repository URLs with '#ref:subdir' or query-style subdir parameters. Confirm that untrusted pull requests, user-supplied repository URLs, and external build definitions cannot select arbitrary subdirectories without validation.

Typical attack path

1. Identify a CI/CD, container build, or developer workflow using BuildKit to build from Git URLs with fragment or subdirectory components.
2. Gain control over the referenced Git repository, pull request source, build URL, branch, tag, or subdirectory fragment used as the build context.
3. Create a repository structure where the selected subdirectory resolves outside the checked-out repository root, commonly by using a symlink to another path on the same mounted filesystem.
4. Trigger the vulnerable BuildKit build using the crafted Git URL subpath.
5. Use the Dockerfile or build commands to read, copy, print, package, or transmit files that were unintentionally included from outside the repository root.
6. Retrieve exposed data from build logs, image layers, pushed images, exported build artifacts, cache outputs, or outbound network destinations.

How to detect it

Review BuildKit, Docker Buildx, Docker daemon, CI runner, and pipeline orchestration logs for builds using Git URL contexts with subdirectory fragments, especially URLs containing a repository fragment and a colon-delimited subpath or query-style subdir parameter. Correlate those builds with repositories containing symlinks at or within the selected subdirectory. Examine build logs for unexpected listing, copying, archiving, or uploading of files that are not part of the intended repository. Inspect produced container images, exported build artifacts, cache exports, and logs for sensitive files or paths that should not originate from the checked-out repository. On Linux build hosts, use auditd, EDR, or filesystem telemetry to identify buildkitd or build containers reading paths outside the expected Git checkout directory during Git-context builds. Also review network egress from build steps shortly after suspicious Git URL subpath builds, because attackers may exfiltrate exposed files during the build.

• .git#
• #:
• subdir=
• :../
• COPY .
• ADD .
• buildkitd
• docker buildx build
• docker build
• --mount=type=bind
• tar czf
• tar -czf
• zip -r
• cat /
• ls -la /
• find /
• curl -X POST
• wget --post-file
• /var/lib/buildkit
• /var/lib/docker/buildkit

What your security team should do

• Prioritize upgrading all BuildKit and Buildx builder environments to BuildKit v0.28.1 or later, especially shared CI/CD runners and systems that build from external repositories.
• Inventory builds that use Git URL build contexts with subdirectory fragments or subdir parameters, and treat those workflows as higher risk until upgraded.
• Temporarily block or require review for untrusted Git URL subpath builds, particularly from forks, pull requests, third-party repositories, or user-provided build requests.
• Harden build worker isolation so BuildKit filesystems do not contain sensitive sibling directories, cached credentials, unrelated repositories, or host-mounted secrets.
• Review recent build logs and image artifacts for evidence that files outside the intended repository were copied, archived, printed, or uploaded.
• Ensure secrets are passed using BuildKit secret mounts or CI secret mechanisms rather than being stored on filesystems visible to general build contexts.
• Add CI policy checks to reject suspicious Git URL fragments, symlinked build-context subdirectories, and Dockerfiles that copy broad filesystem paths into images or artifacts.