CVE-2026-61711: Sandbox Escape via Protobuf SecurityMode Enum Validation Bypass in Moby BuildKit

Moby BuildKit is a highly efficient toolkit designed to convert source code into build artifacts, acting as the backend framework for modern container development suites.

Prior to version 0.31.1, BuildKit contained a logical input validation flaw when deserializing structured gRPC message payloads that carry client-supplied execution directives.

Specifically, the integer value representing the SecurityMode parameter was parsed and accepted from the payload without validation against the known, approved set of Protocol Buffer (protobuf) enum constants.

This behavior exposes a local and network-adjacent attack surface where an execution instance can bypass default Linux security profiles without triggering the security authorization flags.

The root cause of the vulnerability resides in how BuildKit processes protobuf-defined integer enums during the construction of Open Container Initiative (OCI) runtime specifications.

Inside the module executor/oci/spec_linux.go, the function generateSecurityOpts employs a standard Go switch statement to evaluate the security requirements of a build instruction based on the parsed SecurityMode parameter.

The switch statement explicitly checks for SecurityMode_INSECURE (1) and SecurityMode_SANDBOX (0) but lacks a default handler or generic validation logic to capture integers outside of this range.

When a client submits a crafted request specifying an unmapped integer such as 2, the switch matches neither case, allowing execution flow to slide to the end of the block.

The routine then executes a default fallback statement return nil, nil, which hands back a null array of options alongside a null error state, causing the executor to proceed with no configuration profiles.

The vulnerable path in the specification generator ignored non-conforming parameters, resulting in a silent failure to apply safety options:

// Vulnerable block in executor/oci/spec_linux.go
func generateSecurityOpts(mode pb.SecurityMode, apparmorProfile string, selinuxB bool) (opts []oci.SpecOpts, _ error) {
    if selinuxB && !selinux.GetEnabled() {
        return nil, errors.New("selinux is not available")
    }
    switch mode {
    case pb.SecurityMode_INSECURE:
        return []oci.SpecOpts{
            security.WithInsecureSpec(),
            oci.WithWriteableCgroupfs,
        }, nil
    case pb.SecurityMode_SANDBOX:
        // Standard sandbox configuration goes here
        if cdseccomp.IsEnabled() {
            opts = append(opts, withDefaultProfile())
        }
        return opts, nil
    }
    return nil, nil // Silent fall-through on unvalidated integers
}

To address this error, the developers created an input validator helper inside solver/pb/securitymode.go:

package pb
 
import "github.com/pkg/errors"
 
// Patched input validator helper
func ValidateSecurityMode(mode SecurityMode) error {
	switch mode {
	case SecurityMode_SANDBOX, SecurityMode_INSECURE:
		return nil
	default:
		return errors.Errorf("invalid security mode %d", mode)
	}
}

This validator function is now actively called at the entry point of the container initialization code, returning a termination error if any anomalous value is detected.

An attacker begins by preparing low-level builder (LLB) instructions containing a manual modification to the pb.Op structure, setting the SecurityMode property to 2.

The attacker requires permission to issue build instructions or solve requests to an open BuildKit gRPC TCP socket or local UNIX socket.

When BuildKit processes this gRPC request, it skips verification checks for administrative permissions because the value does not register as SecurityMode_INSECURE.

Consequently, the build container is deployed with no active Seccomp profile or AppArmor rules, allowing the container processes to issue raw system calls that would otherwise be blocked.

The successful exploitation of this vulnerability yields a build environment with a degraded security configuration.

While namespace isolation and standard administrative capabilities inside the container remain restricted, the complete removal of Seccomp system call profiling opens up kernel vulnerabilities.

This exposes the host kernel to validation errors, device drivers probing, and other system calls that increase the risk of an escape to the host node.

The CVSS v4.0 rating is calculated as 5.3 due to the low complexity of the request but the reliance on pre-existing gRPC channel authorization.

The recommended approach to address the flaw is updating BuildKit installations to the verified release version 0.31.1.

In environments where updates cannot be deployed immediately, administrators must enforce local loopback binding or strict firewall controls on BuildKit gRPC TCP endpoints.

> [!NOTE] > Restricting standard access to socket-level communication paths prevents unauthenticated network-adjacent clients from transmitting arbitrary execution commands.