CVE-2026-61711: 
Docker Análise e mitigação de vulnerabilidades

CVE-2026-61711 is a security feature bypass vulnerability in Moby BuildKit, a toolkit for converting source code to build artifacts. A custom frontend could place an invalid SecurityMode value in a crafted build request, causing executor/oci/spec_linux.go to treat the unsupported value as a non-sandbox mode without requiring the security.insecure entitlement — thereby disabling Seccomp and AppArmor protections for the build container. All versions up to and including v0.31.0 are affected; the issue was fixed in v0.31.1. It carries a CVSS v4.0 base score of 5.3 (Moderate/Medium) (Github Advisory, BuildKit Release).

The root cause is improper input validation (CWE-20) in the generateSecurityOpts function within executor/oci/spec_linux.go. Prior to the fix, the function used a switch statement that only explicitly handled SecurityMode_INSECURE and SecurityMode_SANDBOX; any other integer value fell through without applying sandbox security options (Seccomp and AppArmor), effectively treating it as an insecure mode without checking for the security.insecure entitlement. An attacker with the ability to submit a custom frontend build request over the network (with low privileges) could craft a build request setting SecurityMode to an invalid enum value (e.g., pb.SecurityMode(2)) to trigger this path. The fix introduced a ValidateSecurityMode() function in solver/pb/securitymode.go that rejects any value other than SecurityMode_SANDBOX or SecurityMode_INSECURE, applied consistently across all platform-specific spec files (Github Advisory, Fix Commit).

Successful exploitation reduces the isolation of the affected build container by disabling Seccomp and AppArmor kernel security profiles, allowing the container to perform syscalls or operations that would otherwise be blocked by those profiles. Notably, Linux capabilities remain restricted, limiting the severity of the bypass. An attacker exploiting this vulnerability could potentially execute restricted syscalls within the build container, access sensitive information, or perform unauthorized operations that the Seccomp/AppArmor profiles were designed to prevent — though full container escape is not directly implied (Github Advisory, Feedly).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time (Feedly). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.357% (29th percentile), indicating a low probability of exploitation in the near term. Exploitation requires low-level privileges (ability to submit custom frontend build requests to a BuildKit instance) and is not automatable according to NVD SSVC assessment.

1. Identify a target: Locate a BuildKit instance (v0.31.0 or earlier) accessible over the network that accepts custom frontend build requests.
2. Craft a malicious build request: Construct a build request using the BuildKit client API or gateway interface, setting the SecurityMode field in an ExecOp or StartRequest to an invalid integer value not defined in the SecurityMode enum (e.g., pb.SecurityMode(2)).
3. Submit the request: Send the crafted request to the BuildKit daemon. Because the invalid value is not validated, generateSecurityOpts in spec_linux.go falls through without applying Seccomp or AppArmor profiles.
4. Execute restricted operations: Within the resulting build container — which now lacks Seccomp and AppArmor enforcement — execute syscalls or operations that would normally be blocked by those profiles, potentially accessing sensitive data or performing unauthorized actions (Github Advisory, Fix Commit).

• Logs: BuildKit daemon logs showing build requests from custom or untrusted frontends with unusual or unexpected SecurityMode values; absence of Seccomp-related log entries for containers that should have sandbox protections applied.
• Process: Build containers where /proc/self/status shows Seccomp: 0 (Seccomp disabled) despite not having the security.insecure entitlement explicitly granted.
• Network: Unexpected or unauthorized connections to the BuildKit gRPC API endpoint from unknown or untrusted frontend images.

Upgrade BuildKit to version v0.31.1 or later, which introduces ValidateSecurityMode() validation that rejects any unknown SecurityMode values before generating executor specs (BuildKit Release). As a workaround for environments that cannot immediately upgrade, restrict the ability to submit custom frontend build requests to trusted users and trusted frontend images only (Github Advisory). Additionally, consider implementing supplementary runtime security controls (e.g., host-level Seccomp policies or mandatory access control) to compensate for the weakened container isolation until patching is complete.

The vulnerability was reported by security researcher Alex0Young and fixed by BuildKit maintainer Tõnis Tiigi. It was released as part of a security patch release (v0.31.1) that also addressed a separate low-severity runtime DoS issue (GHSA-72x6-4j93-7w86). The advisory was rated "Low" severity by the maintainers in the repository advisory, though the GitHub Advisory Database classifies it as "Moderate" based on the CVSS v4.0 score of 5.3 (Github Advisory, BuildKit Release).