BuildKit EUVD-2026-116538

Exploitation requires a malicious actor who already has authorized access to the BuildKit control APIs - concretely, the affected deployment must be a build service that accepts build requests from untrusted users (e.g. a multi-tenant or hosted CI build backend). The attacker submits a build request that sets an extended attribute on a file located outside the BuildKit state directory, including in the trusted. or security. namespaces. LIMITING FACTORS: the vector is local (AV:L) and demands high privileges (PR:H, i.e. a legitimate control-API client), so default single-user/local Docker builds that do not expose the control API to untrusted parties are not realistically exploitable. The only complete fix per the vendor is upgrading to v0.34.1+; the advisory notes the exposure is confined to untrusted-build-service scenarios.

This is a genuine but conditional privilege-escalation issue rather than a broad emergency. The CVSS 4.0 vector (AV:L/AC:L/AT:P/PR:H/UI:N, score 4.5 Medium) tells the real story: exploitation is local to the BuildKit control API and requires high privileges (PR:H), i.e. the attacker must already be an authorized client of the build service. The impact metrics are telling - VC:N/VI:N/VA:N but SI:H/SA:H, meaning no direct impact on the BuildKit process itself but a high integrity (and, per vendor, availability) impact on the subsequent host system, consistent with writing trusted./security. xattrs that can grant a host program elevated privileges. No EPSS score is provided in the input and the issue is NOT on the CISA KEV list, so there is no signal of active exploitation; the only reference is the vendor GHSA advisory, not working exploit code. The vuln.today decision label is 'this_month' (not act_now/emergency), aligning with a patch-promptly-but-not-drop-everything posture. The one notable signal mismatch: the product (BuildKit, Docker's default builder) is extremely widely deployed, yet the vulnerable condition - a build service accepting builds from untrusted clients - is a narrow deployment mode, so real-world exposure is far smaller than the product's footprint suggests. Bottom line: prioritize for multi-tenant/CI build services exposed to untrusted users; low priority for single-tenant local Docker builds.

An organization runs a hosted/CI build service where untrusted users can submit BuildKit build requests over the control API. A malicious user crafts a build that sets an extended attribute on a file outside the BuildKit state directory - for example a trusted. or security. namespace xattr - so that a privileged program on the host later runs with elevated privileges. No public working exploit is identified at time of analysis; only the vendor GHSA advisory exists, and exploitation requires local access to the control API (AV:L, PR:H).