BuildKit EUVD-2026-92545

Exploitation requires the attacker to be able to submit a build context to a BuildKit (buildkitd) daemon - the operation targets the Dockerfile frontend specifically, triggered by including an oversized Dockerfile or .dockerignore file in that context. This is not a default-configuration remote-unauthenticated flaw: the CVSS PR:L indicates low-privilege access is needed to submit a build, and AV:L indicates local/context-level access to the daemon rather than arbitrary internet-facing exploitation. The real-world risk is sharply concentrated on shared or multi-tenant buildkitd instances (CI/CD pipelines, hosted build services), where a crash caused by one submitter interrupts other users' builds; a single-user workstation daemon only harms the attacker's own environment. The limiting factor is that impact is confined to availability (daemon termination) with no code execution, data disclosure, or integrity impact, and the issue is fully mitigated by upgrading to v0.33.1, which rejects such files above 16 MiB.

This is a denial-of-service vulnerability in the BuildKit Dockerfile frontend, and the available signals consistently point to a moderate, bounded risk rather than a top-tier emergency. The vendor-supplied CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:L/UI:N) scores 6.8 and is internally coherent with the description: impact is confined to availability (VA:H) with no confidentiality or integrity impact (VC:N/VI:N), matching CWE-789 (memory allocation with excessive size value) and the described outcome of exhausting memory and crashing buildkitd. The AV:L and PR:L metrics indicate an attacker must be able to submit a build context to the daemon with at least low privileges - i.e., this is an authenticated local/adjacent operation, not blind remote exploitation. No EPSS score, CISA KEV listing, or public POC was provided in the input, so there is no evidence of active or automated exploitation; by precision rule this is 'no public exploit identified at time of analysis.' The practical significance is highest on shared or multi-tenant build infrastructure (CI/CD runners, build-as-a-service), where one tenant's crash interrupts other tenants' builds on the same instance - the description explicitly calls this out. Note one input inconsistency to flag: the 'Information Disclosure' tag directly contradicts the CVSS vector (VC:N, no confidentiality impact) and the described memory-exhaustion behavior; this is a pure availability issue, not information disclosure. Overall: a legitimate but patch-on-normal-cycle issue, elevated mainly where buildkitd is shared across untrusted or semi-trusted workloads.

An attacker with the ability to submit builds to a shared buildkitd instance (for example, a low-privileged user or tenant on a multi-tenant CI/CD build service) crafts a build context whose Dockerfile or .dockerignore file is extremely large. When the frontend loads that file into memory without a size limit, buildkitd allocates memory proportional to the file, exhausts available memory, and is terminated - interrupting all other builds running on the same instance. No public exploit code was identified in the provided data, but the technique is trivial to reproduce given build-submission access.