CVE-2026-61711

BuildKit's CVE-2026-61711 creates an asymmetric security state that should worry you more than the CVSS 5.3 suggests. When an invalid SecurityMode is passed to the BuildKit frontend API, the system silently disables Seccomp and AppArmor while leaving capability restrictions intact. The problem isn't just that protections vanished — it's that operators received no signal this happened. You probably assumed your build isolation was working because you had no evidence otherwise. That's the false confidence interval: you made deployment decisions, workload placements, or trust assumptions based on a security posture that no longer existed. The retained capabilities argument is weaker than it appears. Capabilities and syscall filtering aren't interchangeable safety nets — they're complementary layers where one can compensate for gaps in the other. A container retaining CAP_SYS_PTRACE but missing syscall-level ptrace filtering has a measurably different attack surface than one where both are constrained. The 'capabilities still restricted' framing assumes those restrictions are the right constraints for your workload, which is an assumption rarely verified in practice. This vulnerability bypassed the `security.insecure` entitlement entirely — the explicit consent mechanism operators use to audit builds that opt out of sandboxing. Even if you rely on that entitlement for compliance or audit trails, this bug broke that signal without your knowledge. You cannot trust BuildKit's security mode configuration unless you're actively validating what was actually applied. Detection is the gap you need to close now. Instrument your build pipeline to log the computed security mode for every build step — not just what's requested, but what's actually enforced. If you're running BuildKit in multi-tenant CI/CD, external contributor workflows, or any scenario with untrusted frontend input, treat any SecurityMode parsing anomaly as a security event. The silent failure mode means you won't get an error — you need active verification. Check your BuildKit version against the fix, audit any custom frontends for SecurityMode handling, and verify that `security.insecure` consumption matches your compliance expectations.

Reviewed through automated stages and approved by a human before publication.