CVE-2026-61711: BuildKit Privilege Escalation Vulnerability

CVE-2026-61711 Overview

CVE-2026-61711 is an input validation flaw [CWE-20] in BuildKit, the toolkit used by Docker and other tools to convert source code into build artifacts. Prior to version 0.31.1, a custom frontend could submit a crafted build request containing an invalid SecurityMode value. The executor/oci/spec_linux.go component treated the unsupported value as a non-sandbox mode without requiring the security.insecure entitlement. This disabled Seccomp and AppArmor protections for the build container while Linux capabilities remained restricted. Version 0.31.1 fixes the issue by validating security mode values against the allowed enumeration.

Critical Impact
Build containers can run without Seccomp and AppArmor protections, expanding kernel attack surface and weakening isolation for untrusted build workloads.

Affected Products

moby/buildkit versions prior to 0.31.1
Downstream tooling embedding BuildKit as a build backend
CI/CD systems that accept custom BuildKit frontends

Discovery Timeline

2026-08-19 - CVE-2026-61711 published to NVD
2026-08-20 - Last updated in NVD database

Technical Details for CVE-2026-61711

Vulnerability Analysis

BuildKit exposes two supported security modes for Exec operations: SecurityModeSandbox and SecurityModeInsecure. Selecting the insecure mode normally requires the client to hold the security.insecure entitlement, which grants relaxed isolation for trusted builds. The vulnerable code path in client/llb/exec.go treated any value other than SecurityModeSandbox as insecure without validating that the value was a defined enum member. A custom frontend could send an unrecognized integer as the SecurityMode field in the crafted build request. The executor in executor/oci/spec_linux.go then generated an OCI runtime specification that omitted Seccomp and AppArmor profiles. Linux capability restrictions remained in place, so the flaw is a partial isolation bypass rather than full container escape.

Root Cause

The root cause is an improper input validation error in the security mode handling logic. The code used a not-equal comparison against the sandbox constant instead of an allowlist over supported modes. Any integer outside the defined enumeration was silently accepted and processed as non-sandbox.

Attack Vector

Exploitation requires the ability to submit build requests through a custom LLB frontend to a BuildKit daemon. An attacker authoring a malicious frontend or manipulating LLB protobuf messages can set the SecurityMode field to an out-of-range value. This produces a build container that lacks Seccomp filtering and AppArmor mediation, exposing kernel syscalls that would normally be blocked.

// Patch: client/llb/exec.go — validate exec security modes
// Source: https://github.com/moby/buildkit/commit/3ea6dd0ce7d269cdb8aa23348718e2c1bf64f109

// Before (vulnerable): any non-sandbox value was treated as insecure
// if security != SecurityModeSandbox {
//     addCap(&e.constraints, pb.CapExecMetaSecurity)
// }

// After (fixed): only defined enum members are accepted
switch security {
case SecurityModeSandbox:
case SecurityModeInsecure:
    addCap(&e.constraints, pb.CapExecMetaSecurity)
default:
    return "", nil, nil, nil, pb.ValidateSecurityMode(security)
}

A new validator was added in solver/pb/securitymode.go:

// Source: https://github.com/moby/buildkit/commit/3ea6dd0ce7d269cdb8aa23348718e2c1bf64f109
package pb

import "github.com/pkg/errors"

func ValidateSecurityMode(mode SecurityMode) error {
    switch mode {
    case SecurityMode_SANDBOX, SecurityMode_INSECURE:
        return nil
    default:
        return errors.Errorf("invalid security mode %d", mode)
    }
}

Detection Methods for CVE-2026-61711

Indicators of Compromise

Build containers spawned by BuildKit without Seccomp profiles applied, visible in container runtime metadata or /proc/<pid>/statusSeccomp: field showing 0.
Absence of AppArmor labels on BuildKit-launched build processes when policy would normally apply.
BuildKit daemon logs showing frontend requests with unusual or non-standard SecurityMode values.

Detection Strategies

Inventory BuildKit installations across CI runners and developer workstations, flagging versions earlier than 0.31.1.
Audit which entities can submit custom frontends to a BuildKit daemon and correlate against user identity records.
Compare expected OCI runtime specs for build containers against actual specs to identify missing Seccomp or AppArmor settings.

Monitoring Recommendations

Monitor BuildKit daemon socket access and log all frontend image references used in build requests.
Alert on build containers making unexpected syscalls that would normally be blocked by the default Docker Seccomp profile.
Track BuildKit version rollout progress and generate alerts for daemons that remain on affected releases.

How to Mitigate CVE-2026-61711

Immediate Actions Required

Upgrade BuildKit to version 0.31.1 or later on all builders, CI runners, and Docker installations that ship BuildKit.
Restrict access to the BuildKit daemon socket to trusted users and CI service accounts only.
Review CI pipeline configurations and reject use of untrusted or unpinned custom LLB frontends.

Patch Information

The fix is available in the moby/buildkit v0.31.1 release. Technical details are documented in the GitHub Security Advisory GHSA-7236-3392-c5c6 and the corresponding validation commit.

Workarounds

Disallow custom frontends by pinning builds to the official Dockerfile frontend image digest.
Deny the security.insecure entitlement on all BuildKit daemons that do not require it, reducing exposure even if unexpected modes leak through.
Run BuildKit inside a rootless configuration or a hardened sandbox to add a defense-in-depth layer around the executor.

bash

# Verify installed BuildKit version and upgrade if affected
buildctl --version

# Example: pull the patched release container image
docker pull moby/buildkit:v0.31.1

# Restrict daemon to disallow the insecure entitlement (systemd drop-in)
# /etc/systemd/system/buildkit.service.d/override.conf
# [Service]
# ExecStart=
# ExecStart=/usr/bin/buildkitd --allow-insecure-entitlement=