BuildKit: crafted upload request writes files outside the daemon-controlled state directory

Impact

A client that can reach the BuildKit control API can craft an upload request whose files land outside the BuildKit state directory, writing to arbitrary paths the daemon can reach. On a shared build node this is a write primitive against whatever else the daemon user owns — other tenants' build state, cached layers, or files on mounted host paths — which puts image integrity at stake for everything built on that node. GPU fleets commonly run a small pool of shared builders producing the CUDA and inference images the rest of the cluster pulls, so a poisoned artifact propagates far beyond the build host. The CVSS vector rates integrity and availability high with no confidentiality loss.

Who can reach it

Anyone able to issue builds against the BuildKit control API — the advisory notes the client needs valid permission to reach that API, so this is authenticated (or reachable wherever authentication is bypassed or the socket is exposed unauthenticated).

What to do

Upgrade BuildKit to 0.31.2 and restart the buildkitd daemon or the builder pods; in-flight builds are lost but no host reboot is required. Until then, confirm which principals can reach the control API or the buildkitd socket and narrow that set — the flaw needs API access, so restricting the socket is a real mitigation.

References