CVE-2026-61711: 
Datadog Agent vulnerability analysis and mitigation

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 — effectively 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 (Medium/Moderate) (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, silently disabling Seccomp and AppArmor without checking for the security.insecure entitlement. The fix introduces a new ValidateSecurityMode() function in solver/pb/securitymode.go that rejects any SecurityMode value other than SANDBOX or INSECURE, and this validation is applied at the start of generateSecurityOpts across all platform-specific spec files (Linux, Darwin, FreeBSD, Windows) (Github Advisory, Patch Commit). An attacker must have the ability to submit a custom frontend build request to a vulnerable BuildKit instance.

Successful exploitation reduces the security isolation of the build container by disabling Seccomp and AppArmor profiles, allowing the container to perform system calls or operations that would otherwise be blocked by these mandatory access controls. Linux capabilities remain restricted, limiting the severity of the bypass. The impact is primarily a weakening of the defense-in-depth posture of the build environment, potentially enabling an attacker to execute restricted operations, access sensitive build-time data, or facilitate further exploitation if combined with other vulnerabilities (Github Advisory, Feedly).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at the time of disclosure (Feedly). The EPSS score is 0.0, reflecting very low current exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires low privileges (the ability to submit a custom frontend build request) and no user interaction, but is constrained to users with access to the BuildKit API.

1. Gain build submission access: Obtain credentials or access to a BuildKit instance that accepts custom frontend build requests (e.g., via a CI/CD pipeline or direct API access).
2. Craft a malicious build request: Construct a build request (raw LLB or via the gateway API) that sets the SecurityMode field of an exec operation to an invalid integer value — for example, pb.SecurityMode(2) — which is neither SecurityMode_SANDBOX (0) nor SecurityMode_INSECURE (1).
3. Submit the request: Send the crafted build request to the vulnerable BuildKit daemon (versions ≤ v0.31.0). The daemon's generateSecurityOpts function fails to validate the unknown mode and skips applying Seccomp and AppArmor profiles.
4. Execute restricted operations: Within the resulting build container, perform system calls or actions that would normally be blocked by Seccomp or AppArmor, such as reading /proc/self/status to confirm Seccomp: 0, or attempting operations restricted by the default AppArmor profile (Patch Commit, Github Advisory).

• Logs: BuildKit daemon logs showing build requests from custom or untrusted frontends with unusual or unrecognized SecurityMode values; absence of expected Seccomp/AppArmor enforcement messages for build containers.
• Process: Build containers where /proc/self/status reports Seccomp: 0 (Seccomp disabled) when sandbox mode is expected; processes within build containers performing system calls that should be blocked by the default Seccomp profile.
• Network: Unexpected outbound connections from build containers that would normally be restricted by AppArmor profiles.

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 frontends only (Github Advisory). Additionally, consider implementing supplementary runtime security controls (e.g., host-level Seccomp policies or network segmentation) to compensate for the reduced 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 runtime DoS issue (GHSA-72x6-4j93-7w86), and was classified as low/moderate severity by the maintainers (BuildKit Release, Github Advisory). No significant broader community or media reactions have been observed beyond the standard advisory publication.