Source: Docker Blog — https://www.docker.com/blog/mitigating-cve-2026-31431-copy-fail-in-docker-engine/
CVE-2026-31431 is a Linux kernel vulnerability, but the Docker-relevant question is narrower: can a container reach the kernel interface used by the exploit? According to Docker, older default Docker Engine profiles allowed containers to create AF_ALG sockets, which are part of the syscall surface involved.
Docker says its own infrastructure is not compromised. That matters, but it is not the same as saying every Docker host is safe. Exposure depends on the Docker Engine version and the container security profile in use.
What Docker says is exposed#
Docker’s mitigation note says Docker Engine default profiles before v29.4.3 allowed containers to create AF_ALG sockets. That is the key detail.
AF_ALG is a Linux socket family used to access kernel crypto APIs. Docker’s post ties the CVE’s exploit path to that socket surface. In practical terms, the risk is not that Docker shipped the kernel bug. The risk is that container policy may have left a path open to the vulnerable kernel feature.
Docker states that users are not exposed if they are running Docker Engine v29.4.3 or later. The source excerpt also indicates there are other safe configurations, but the provided material is cut off after “OR a…”, so this note should not guess the rest. The reliable takeaway from the available source is simple: v29.4.3 is the clean version boundary Docker names.
Why this matters for container operators#
This is the kind of vulnerability that can get misread in both directions.
One overclaim is: “Docker was compromised.” Docker explicitly says the CVE does not compromise Docker infrastructure. The source does not support treating this as a Docker platform breach.
The other overclaim is: “It is only a kernel issue, so Docker users do not need to care.” That is also too soft. Containers share the host kernel. If a container can reach the vulnerable kernel interface, the container boundary becomes part of the risk calculation.
That is why default profiles matter. Seccomp, AppArmor, and related runtime policies are not cosmetic hardening. They decide which kernel paths a workload can touch. A kernel vulnerability becomes easier to contain when the container cannot reach the relevant interface in the first place.
The useful lesson is not “containers are broken.” It is more specific: container isolation is strongest when runtime policy removes unnecessary kernel surface. A default that permits too much may be harmless for years, then become important when a kernel bug lands on that exact path.
What to check now#
Start with the Docker Engine version on Linux hosts. If the host is running Docker Engine v29.4.3 or later, Docker says it is not exposed under the condition described in the blog excerpt.
For older engines, treat the host as needing review. The immediate question is whether containers can create AF_ALG sockets under the active runtime policy. Do not assume your environment matches Docker defaults if you use custom seccomp profiles, hardened baselines, or orchestration-level policy controls.
Useful checks:
- Confirm Docker Engine version across Linux hosts, not only developer laptops.
- Identify hosts still below v29.4.3.
- Review whether workloads use Docker’s default profiles or custom profiles.
- Check whether AF_ALG socket creation is allowed for containers on older engines.
- Prioritize internet-facing, multi-tenant, CI, and untrusted workload hosts first.
CI runners deserve extra attention. They often execute third-party code, build untrusted branches, and run with broad container privileges for convenience. That combination turns “kernel surface reachable from a container” into a higher-priority operational issue.
What not to overclaim#
The available source material does not state that exploitation is active in the wild. It does not provide a full exploit chain, affected kernel version list, or proof that every pre-v29.4.3 Docker Engine deployment is exploitable. It also does not say Docker infrastructure was breached.
The safer reading is narrower and more useful: Docker found that older default Docker Engine profiles allowed access to a Linux kernel socket surface used by CVE-2026-31431, and Docker Engine v29.4.3 changes that exposure boundary.
That is enough to justify patching and policy review. It is not enough to invent incident impact.
Practical takeaway#
Update Docker Engine where possible. If you cannot update immediately, review container security profiles and restrict AF_ALG socket creation where your workloads do not require it.
The operational priority is clear: close the kernel interface from containers first, then validate the host kernel patch path through your normal Linux distribution channel. Docker can reduce the container-side reachability. The underlying CVE still belongs to the kernel.