Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
9 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact Maliciously crafted base image or build can cause a Denial of Service (DoS) condition. When creating a container from this image, memory exhaustion occurs, leading to an Out Of Memory (OOM) kill of the buildkitd process. Patches Issue is fixed in BuildKit v0.31.1+ Workarounds Use trusted build sources. References This is BuildKit variant of containerd advisory https://github.com/containerd/containerd/security/advisories/GHSA-jpcc-p29g-p8mq
Recommended action: Upgrade to 0.31.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A custom frontend could send a crafted build request that disabled Seccomp and AppArmor protections for the build container, even if the user did not explicitly allow the security.insecure entitlement. Other security measures, like Linux capabilities were still applied to these containers. Patches Problem has been fixed in versions v0.31.1+ Workarounds Only use BuildKit frontends from trusted providers.
Recommended action: Upgrade to 0.31.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Insufficient validation of Git URL fragment subdir components (<url#<ref:<subdir, docs) may allow access to files outside the checked-out Git repository root. Possible access is limited to files on the same mounted filesystem. Patches The issue has been fixed in version v0.28.1 Workarounds The issue affects only builds that use Git URLs with a subpath component. Avoid building Dockerfiles from untrusted sources or using the subdir component from an untrusted Git repository where the subdir component could point to a symlink.
Recommended action: Upgrade to 0.28.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When using a custom BuildKit frontend, the frontend can craft an API message that causes files to be written outside of the BuildKit state directory for the execution context. Patches The issue has been fixed in v0.28.1+ Workarounds Issue requires using an untrusted BuildKit frontend set with #syntax or --build-arg BUILDKITSYNTAX. Using these options with a well-known frontend image like docker/dockerfile is not affected.
Recommended action: Upgrade to 0.28.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A malicious BuildKit client or frontend could craft a request that could lead to BuildKit daemon crashing with a panic. Patches The issue has been fixed in v0.12.5 Workarounds Avoid using BuildKit frontends from untrusted sources. A frontend image is usually specified as the #syntax line on your Dockerfile, or with --frontend flag when using buildctl build command. References
Recommended action: Upgrade to 0.12.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Two malicious build steps running in parallel sharing the same cache mounts with subpaths could cause a race condition that can lead to files from the host system being accessible to the build container. Patches The issue has been fixed in v0.12.5 Workarounds Avoid using BuildKit frontend from an untrusted source or building an untrusted Dockerfile containing cache mounts with --mount=type=cache,source=... options. References https://www.openwall.com/lists/oss-security/2019/05/28/1
Recommended action: Upgrade to 0.12.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A malicious BuildKit frontend or Dockerfile using RUN --mount could trick the feature that removes empty files created for the mountpoints into removing a file outside the container, from the host system. Patches The issue has been fixed in v0.12.5 Workarounds Avoid using BuildKit frontend from an untrusted source or building an untrusted Dockerfile containing RUN --mount feature. References
Recommended action: Upgrade to 0.12.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact In addition to running containers as build steps, BuildKit also provides APIs for running interactive containers based on built images. It was possible to use these APIs to ask BuildKit to run a container with elevated privileges. Normally, running such containers is only allowed if special security.insecure entitlement is enabled both by buildkitd configuration and allowed by the user initializing the build request. Patches The issue has been fixed in v0.12.5 . Workarounds Avoid using BuildKit frontends from untrusted sources. A frontend image is usually specified as the #syntax line on your Dockerfile, or with --frontend flag when using buildctl build command. References
Recommended action: Upgrade to 0.12.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When the user sends a build request that contains a Git URL that contains credentials and the build creates a provenance attestation describing that build, these credentials could be visible from the provenance attestation. Git URL can be passed in two ways: 1) Invoking build directly from a URL with credentials. Equivalent in docker buildx would be 2) If the client sends additional VCS info hint parameters on builds from a local source. Usually, that would mean reading the origin URL from .git/config file. Thanks to Oscar Alberto Tovar for discovering the issue. Impact When a build is performed under specific conditions where credentials were passed to BuildKit they may be visible to everyone who has access to provenance attestation. Provenance attestations and VCS info hints were added in version v0.11.0. Previous versions are not vulnerable. In v0.10, when building directly from Git URL, the same URL could be visible in BuildInfo structure that is a predecessor of Provenance…
Recommended action: Upgrade to 0.11.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.