Container defense-in-depth relies on two distinct enforcement layers: access control at the management daemon and resource isolation inside the host kernel. Two major vulnerabilities disclosed in 2026—Moby/Docker Engine CVE-2026-34040 and Linux kernel CVE-2026-31431 (known as Copy Fail)—demonstrate how fast those boundaries collapse when middleware defaults to failing open and kernel zero-copy optimizations violate read-only memory invariants.
When we treat container runtimes and the host kernel as black boxes, we assume policy checks see the exact same data the runtime executes, and that read-only file descriptors cannot mutate shared host memory. Both assumptions broke this year. Understanding the root mechanics of these flaws provides a blueprint for hardening container hosts beyond routine binary patching.
CVE-2026-34040: When Daemon Middleware Fails Open
In shared infrastructure, platform teams frequently rely on Docker Authorization (AuthZ) plugins to restrict what authenticated users or CI runners can ask the Docker daemon to do. An AuthZ plugin inspects incoming API requests over HTTP—such as calls to create a container—and blocks dangerous configurations like --privileged flags or host root filesystem mounts.
CVE-2026-34040 (CVSS 8.8, published March 2026) exposed a severe parsing discrepancy in all Moby and Docker Engine versions prior to 29.3.1 (and Docker Desktop prior to 4.66.1). The flaw represents an incomplete fix for an earlier bypass, CVE-2024-41110, which only addressed zero-length request bodies.
The root cause lies in how the daemon buffered HTTP request streams before forwarding them to external AuthZ plugins. When the Docker API received a request whose body exceeded an internal buffer allocation threshold (over 1 MB), the proxy handler silently dropped the request body before querying the AuthZ plugin.
As a result, the Policy Decision Point (the AuthZ plugin) received only the request headers and URI alongside an empty body. Seeing no policy violations in an empty payload, the plugin returned an approval decision. However, the Policy Enforcement Point (the Docker daemon) retained the full original stream and proceeded to execute the uninspected request body. Any security middleware that evaluates a truncated representation of an input while passing the full input downstream creates an architectural bypass.
CVE-2026-31431: Copy Fail and In-Memory Page Cache Corruption
Even if an authorization layer holds firm, containers still share a single host Linux kernel. Disclosed in April 2026, CVE-2026-31431 (CVSS 7.8, dubbed "Copy Fail") revealed a nine-year-old logic bug in the kernel's user-space cryptographic subsystem (AF_ALG), specifically within crypto/algif_aead.c.
The vulnerability dates back to a 2017 performance commit (72548b093ee3). To avoid memory allocation overhead during Authenticated Encryption with Associated Data (AEAD) operations, the commit enabled in-place processing where the source scatterlist shared references with the writable destination scatterlist.
The isolation failure occurs when a local process combines this in-place crypto path with the splice() system call. When splice() streams data from a read-only file descriptor into an AF_ALG socket, the kernel avoids copying bytes and instead inserts direct references to the file's backing Page Cache pages into the scatterlist. Because algif_aead operated in-place, those read-only Page Cache references were placed directly into the writable destination scatterlist. When recvmsg() completed the cryptographic operation, the output was written straight into the shared Page Cache in RAM.
Crucially, because this write bypasses standard filesystem DAC/MAC permission checks and normal write paths, the modified memory pages are never marked dirty and never flushed to disk. Disk-based File Integrity Monitoring (FIM) tools see clean files on storage while every process on the host—across container boundaries—executes mutated code from memory.
Architectural Comparison: Daemon vs. Kernel Boundaries
Both vulnerabilities stem from optimizations or buffer handling that broke security invariants across a trust boundary:
| Architectural Dimension | Docker AuthZ Layer (CVE-2026-34040) | Kernel Isolation Layer (CVE-2026-31431) |
|---|---|---|
| Boundary Location | Userspace Daemon (Moby HTTP API Middleware) | Kernel Subsystem (algif_aead / Page Cache) |
| Failure Mode | Buffer truncation & fail-open forwarding | Zero-copy sharing of read-only pages as writable |
| Affected Data Structure | HTTP Request Body Stream (> 1 MB) | In-memory Page Cache (scatterlist buffers) |
| Security Impact | Policy bypass on container creation APIs | Cross-container read-only memory tampering |
| Core Remediation | Upgrade to 29.3.1; enforce fail-closed checks | Revert in-place AEAD; block AF_ALG via Seccomp |
Engineering Defenses and Patch Remediation
Patching the binaries is mandatory, but resilient infrastructure requires eliminating the underlying attack surfaces so similar bugs cannot be exploited in the future.
1. Eliminating the Kernel Crypto Attack Surface
Upstream Linux kernel updates fix CVE-2026-31431 by reverting algif_aead to out-of-place processing, ensuring read-only Page Cache pages are never placed in writable destination scatterlists.
If you cannot reboot hosts immediately—and your kernel was not compiled with CONFIG_CRYPTO_USER_API_AEAD=y statically built-in—disable and unload the vulnerable module on the host:
echo "install algif_aead /bin/false" | sudo tee /etc/modprobe.d/disable-algif-aead.conf
sudo rmmod algif_aead 2>/dev/null || true
More importantly, standard containerized web apps and microservices never need kernel-space socket cryptography—they use user-space libraries like OpenSSL. Harden your default container Seccomp profiles (across Docker, containerd, or CRI-O) to explicitly block Address Family 38 (AF_ALG) in the socket syscall, which neutralizes this path even on statically compiled kernels:
{
"defaultAction": "SCMP_ACT_ALLOW",
"syscalls": [
{
"names": ["socket"],
"action": "SCMP_ACT_ERRNO",
"errnoRet": 1,
"args": [
{
"index": 0,
"value": 38,
"op": "SCMP_CMP_EQ"
}
]
}
]
}
2. Enforcing Fail-Closed Daemon Policies and User Namespaces
For CVE-2026-34040, upgrade Docker Engine to 29.3.1 or newer (and Docker Desktop to 4.66.1). The patch ensures the entire request body stream is synchronized with the AuthZ plugin before scheduling any runtime action.
As an architectural defense, never expose the Docker daemon TCP socket directly to internal networks; restrict access to local Unix domain sockets or enforce mutual TLS (mTLS) behind an API proxy that enforces strict payload size limits. Finally, enable User Namespaces (userns) so that UID 0 inside a container maps to an unprivileged UID on the host, containing the blast radius if an isolation boundary ever fails.
Loading comments…