Kubernetes Container Escape Audit v4.7.3: catching a Docker daemon bypass your policy engine can't see Most…
Liam R. — Freelance Penetration Tester
Kubernetes Container Escape Audit v4.7.3: catching a Docker daemon bypass your policy engine can't see
Most of what container_escape_audit.sh checks lives inside the container looking out — capabilities, mounts, kernel exposure, runtime binaries reachable through a host path. v4.7.3 adds something different: check 53, the tool's first check aimed squarely at the Docker daemon itself, and it closes a real gap that a compromised container, a misconfigured cluster, or a stale Docker Engine could leave wide open.
The problem: your AuthZ plugin might be approving things it never saw
If you run a Docker AuthZ plugin — OPA, Prisma Cloud, or something custom — to enforce policy on what containers can be created, you're trusting that the plugin actually inspects every request before the daemon acts on it.
CVE-2026-34040 (CVSS 8.8) breaks that assumption. The 2024 fix for CVE-2024-41110 closed the zero-length request body bypass, where an empty body slipped past AuthZ inspection. But it missed the opposite case: pad a request body past 1MB, and Docker's middleware silently truncates what the AuthZ plugin gets to see — while the daemon itself still processes the full, untruncated request.
The practical effect: an attacker sends a container-create request with --privileged and a full host filesystem mount, padded past the 1MB boundary. The AuthZ plugin sees what looks like an empty, harmless request and waves it through. The daemon creates the container exactly as requested. No race condition, no timing dependency — one HTTP request.
It's worth being precise about scope: this only matters if you're running an AuthZ plugin that inspects request bodies for policy decisions. A vanilla Docker install with no AuthZ plugin configured isn't affected by this particular CVE — though it's still worth patching. Fixed in Docker Engine 29.3.1 / Docker Desktop 4.66.1.
What check 53 does
Detection is layered the same way checks 25, 26, and 52 already work — try the most informative source first, fall back honestly when it's not available:
1. Daemon socket query (preferred). If /var/run/docker.sock (or a host-mounted equivalent) is reachable, the check queries /version and /info directly over the Unix socket. This is the only vantage point that reveals both the exact Server Version and whether an AuthZ plugin is actually configured — which is the precondition for this CVE to matter at all.
2. Binary fallback. If the socket isn't reachable but a dockerd binary is, via a host-mounted path (the same trick check 52 uses for runc/containerd/cri-o), the check reports the engine version from dockerd --version. It's explicit that AuthZ-plugin status can't be confirmed this way, and flags the finding as verify-required rather than assuming either safety or vulnerability.
3. Unknown, not safe. If neither is reachable, it says so plainly.
Severity is graduated to match actual exploitability, not just version age:
| Condition | Severity |
|---|---|
| Pre-29.3.1 and AuthZ plugin configured | CRITICAL |
| Pre-29.3.1, no AuthZ plugin detected | MEDIUM (hygiene finding) |
| Patched (≥29.3.1) | INFO |
| Binary reachable, socket not — plugin status unknown | MEDIUM, verify-required |
| Nothing reachable | INFO — explicitly "unknown," never scored as passing |
What's not done yet
CVE-2026-34040 isn't in cve_checks.conf — check 53 is a standalone script check for now, the same way check_nvidiascape and check_runc_masked_path are. That means it won't show up by CVE ID in the config-driven CVE report used for inventory/compliance tracking, even though the behavioral detection is fully live.
The plan for a follow-up release: add a check_type=manual conf entry for CVE-2026-34040, and extend the engine's cross-reference logic (the same mechanism that already lets CVE-2019-5736 and CVE-2024-21626 pull a live verdict from check 52's cached runc detection) to consult check 53's result instead of falling back to a generic advisory.
Upgrading
Version: 4.7.2 → 4.7.3
Checks: 52 → 53
Grab the release, verify the SLSA provenance as usual, and re-run against any host or cluster where Docker AuthZ plugins are part of your policy enforcement story — that's the population this actually matters for.
Full technical detail is in the README and the CVE-2026-34040 write-up.
3 reactions · 0 comments