CVE-2026-31431 "Copy Fail" — why the kernel matters
A trivial local privilege escalation in the Linux kernel. Whichever container distribution runs on top is irrelevant: the mitigation belongs on the host. We explain what the vulnerability means technically, and what we have rolled out for our hosting clients.
The vulnerability discussed since this week, CVE-2026-31431, nicknamed "Copy Fail" by the community, sits in the Linux kernel itself. We have been getting questions since yesterday, and have pulled the answers together here, including the measures we have rolled out for our managed-hosting clients.
Executive summary
This is a kernel vulnerability, not a container one. Which container distribution runs on top is irrelevant: Debian, Alpine, Ubuntu, Wolfi are equally exposed because none of them ships a kernel of its own. As of today, no broadly available patches exist; only workarounds. We have applied the effective host-level mitigations across all managed-hosting clients.
What Copy Fail is, technically
CVE-2026-31431 enables a local privilege escalation to root. The public proof-of-concept fits on a single A4 page and requires no rare prerequisites. It uses standard kernel functionality that is active in virtually every Linux system, and works across distributions.
Technically, the issue lives in the crypto subsystem, specifically in the AF_ALG interface and the handling of certain memory operations. The detailed write-up at copy.fail makes the impact clear.
Why containers do not save you here
A common fallacy goes: "If the container is secure, the system is secure." That holds for many classes of vulnerabilities. For kernel flaws it does not.
Containers, whether based on Debian, Alpine or Wolfi, ship no kernel of their own. They use the host system's kernel. Container isolation is a user-space construction, enforced by the kernel itself. As soon as a process inside the container reaches into the kernel and escalates there, the isolation is bypassed.
This is conceptually similar to the supply-chain risks we have written about, for example the image audit after the IDS alert or the Bitwarden CLI incident of 22 April. There, too, the attack operates below what container hardening can cover.
Wolfi OS in proper context
At Moselwal we use Wolfi OS as our container base. The framing matters: Wolfi is an undistro, a pure userland with no kernel of its own. Wolfi uses the host kernel entirely. Two consequences follow: Wolfi is not the source of the vulnerability, and Wolfi cannot fix it either. Responsibility sits with the host.
For the same reason we moved away from compose.yaml across all projects a few weeks ago and now build container topologies declaratively. Clear layers let us pin responsibility per incident, as in this case to the host kernel.
What we actually did
Since no broadly available kernel patches exist yet, we have implemented the recommended workarounds:
- Audit of all affected hosts in our managed-hosting estate
- Disabling
algif_aeadvia modprobe blacklist - Restricting access to
crypto_user - Validation by reproducing the public PoC after mitigation
A host counts as cleared only once the exploit fails in our validation. This is exactly what we do for clients day in, day out under DevSecOps as a Service and our external IT department.
What we deliberately did not do
We did not rebuild any container images, because the cause does not live there. Generic hardening exercises "while we are at it" we skipped, because they would have diluted the validation of the actual mitigation.
Who is most affected
The vulnerability is particularly dangerous where many workloads share the same kernel: container hosts in multi-tenant setups, self-managed Kubernetes workers, CI/CD runners. We have argued at length elsewhere why CI pipelines, of all places, are the largest concentration point for escalations.
It is precisely for this class of risk that we are wiring AI security audits into every release, as an early-warning system for trivially exploitable CVEs before day zero.
Bottom line
CVE-2026-31431 is a kernel-only vulnerability. Container distributions, Wolfi included, can neither cause it nor cure it. Until an official kernel patch ships, we mitigate at host level; once the patch is stable, we will roll it out.
Frequently asked questions about Copy Fail
Do we need to rebuild our Wolfi images?+
No. The vulnerability sits in the host kernel, not in the images. Rebuilds would be activity for activity’s sake and only burn pipeline time — that holds for Wolfi just as for any other container base.
Why is algif_aead loaded at all? Who needs it?+
AF_ALG is a user-space interface to the kernel crypto subsystem. Very few applications use it in production. Disabling it via modprobe blacklist is therefore typically a no-op for normal operations.
How do you test that the mitigations are effective?+
We reproduce the public PoC from copy.fail after applying the mitigation. A host counts as cleared only when the escalation fails. A configuration line entered is not enough.
Are cloud providers like AWS, Hetzner and others mitigated automatically?+
Not automatically. Managed Kubernetes providers often ship worker images with mitigations included. Self-managed workers on EC2 or bare metal are your responsibility, and part of our audit.
When will the official kernel patch land?+
As of 30 April 2026, no final mainline patch is available. Distributors will ship the patch after backporting. We track the kernel mailing list and apply the fix once it is stable and our validation has run.
What if we cannot do this in-house?+
That is exactly what DevSecOps as a Service and our external IT department are for. We mitigate on your behalf, document the procedure in an audit-ready way, and hand back a verified state.
We test your hosts against Copy Fail.
You give us access to your hosts; we reproduce the public PoC, mitigate where needed, and hand back an audit-ready report.