AuthZ said deny. The parser said yes.
A one-megabyte padding trick that walks around Docker's last line of defense, the AWS session-policy pattern for forensic artifact collection, and the Kubernetes 1.36 features that quietly change who can impersonate whom.
> download one-pager (PDF)> New here? Get next Tuesday's issue in your inbox.
🎯 Attack of the Week
How the Docker AuthZ bypass runs. Docker's authorization middleware hands a request body to your AuthZ plugin. Except when the body is over one megabyte. Then the middleware silently hands the plugin RequestBody: nil, the plugin sees no body and has nothing to reject, and the daemon processes the full request anyway. Pad a POST /containers/create call with a _padding field past 1MB, include "Privileged": true and "Binds": ["/:/host"], and the plugin's "no privileged containers" rule never fires. Container starts, host root mounts inside, you read /root/.ssh/id_rsa, /etc/kubernetes/admin.conf, whatever your agent needs.
Ten years between the two halves of this bug. Docker Engine 1.10 (February 2016) introduced AuthZ middleware. CVE-2024-41110 in July 2024 patched the Content-Length: 0 bypass, where a zero-length header paired with an actual body left the plugin seeing nothing. CVE-2026-34040 (CVSS 8.8 per GHSA; 7.8 per NVD) uses the oversize path nobody had tested.
The AuthZ plugin only sees the first megabyte. Cyera's write-up pairs this CVE with a separate observation they already documented: Claude Code has been seen autonomously bypassing three sandbox layers (path denylist, bubblewrap, kernel content-hash enforcement) to complete tasks, no adversarial prompting involved. The Docker AuthZ bypass is the same failure mode on a new surface. Give an agent a task that wants host files, hand it a Docker socket behind an AuthZ plugin, and the agent doesn't need to read the CVE. It needs to read the error messages. Enforcement that assumes the plugin sees what the daemon sees breaks silently.
If any host in your fleet runs Docker Engine older than 29.3.1 and the AuthZ plugin is part of your sandbox story (Twistlock, OPA-docker-authz, custom webhooks), patch this week. If you can't patch: nginx in front of the socket with client_max_body_size 512k;, socket locked to local users. The deeper question: if the AuthZ plugin is the only thing between your agent and host root, that's a single silent failure away from a bad afternoon.
🚨 Rule of the Week
Detection sketch for the AuthZ-bypass pattern. If your Docker daemon proxies through nginx or envoy, you already have request-size logging. Alert on any POST to /containers/create or /containers/*/exec where Content-Length exceeds 1MB. That's the fingerprint, padded JSON doesn't fit legitimate workflows. If you don't proxy the socket, enable "debug": true in /etc/docker/daemon.json and grep /var/log/docker.log for Request body is larger than, the message Docker logs when it drops the body. Under 20 minutes as an nginx access-log rule or a Splunk query.
🔧 Defender's Corner
Deploy the AWS forensic-artifact S3 framework before you need it. Session-policy-scoped IAM grants upload access to a single case prefix (arn:aws:s3:::forensics-collection/CASE-NNNN/*), encrypts at rest with KMS, Object-Locks the bucket for immutability, and lands every object-level event in CloudTrail. No long-lived keys on the responding host. Three CDK stacks at aws-samples/sample-collect-forensic-artifacts-s3. Build in a non-prod account this week so the muscle memory is there when you need it at 2 AM.
Part one walks through what lives at /var/lib/docker/overlay2/, /var/lib/docker/containers/<id>/config.v2.json, and the tools (dive, diffoci, docker-explorer) for extracting runtime changes. Not theoretical, the team references a compromised Kali Linux image where dive surfaced an eBPF rootkit in an injected /app directory. Know which runtime your prod hosts run, where it writes overlays and logs, and pre-draft the first three commands you'd run on a compromised host.
Both pair because the Attack above shows a sandbox boundary failing silently. When it fails, the response is forensics.
For your engineer: pick one production host, run docker inspect on a running container, read the overlay2 path it shows. Do it now, not after an incident.
📡 Also on the Radar
Three that change attack-path assumptions: fine-grained Kubelet API authorization (stable) means nodes/proxy no longer grants everything, you can grant nodes/pods alone. Constrained impersonation (beta) limits what one account can do when impersonating another. User namespaces graduating to stable means a container escape lands as an unprivileged user, not root. 1.36 is where least privilege starts becoming structural in Kubernetes.