BuildKit: invalid SecurityMode disables Seccomp and AppArmor without the insecure entitlement

Impact

A custom frontend can place an unsupported SecurityMode value in a crafted build request; spec_linux.go treats the unrecognized value as a non-sandbox mode and skips the security.insecure entitlement check. The build container then runs with Seccomp and AppArmor off. Linux capabilities remain restricted, so this is not a direct escape, but it strips two of the layers standing between an untrusted build and the host kernel and widens the syscall surface a kernel exploit can reach. On a shared build farm — including GPU nodes doing image builds alongside tenant workloads — the entitlement system exists so the operator decides which builds get to drop sandboxing; this bypasses that decision without any signal.

Who can reach it

Anyone who can submit a build request with a custom frontend to the BuildKit daemon. Network-reachable and low-privileged in the usual buildkitd-as-a-shared-service deployment.

What to do

Upgrade BuildKit to 0.31.1 and restart buildkitd, or update the builder image if you run BuildKit as a Kubernetes builder deployment. No node drain or reboot. If you allow untrusted or third-party frontends, review who can submit builds while rolling the fix.

References