CVE-2026-31431 (Copy Fail) - How We Mitigated It

Last week a serious Linux kernel local privilege escalation was disclosed: CVE-2026-31431, nicknamed "Copy Fail". It affects a wide range of kernel versions across modern Linux distributions, and a public exploit appeared quickly after disclosure.

I want to be upfront about what happened, what it means for Appbox, and what we've done about it. Short version: thanks to how our containers are built, apps running with user namespace remapping were already protected against this turning into host root even before patched kernels were rolled out. Yesterday (May 4, 2026), we also performed emergency maintenance to upgrade every server to a patched kernel, so the bug is now fully gone from our fleet.

What is "Copy Fail"?

CVE-2026-31431 is a flaw in the kernel's AF_ALG cryptographic API. By binding to a specific cipher (authencesn(hmac(sha256),cbc(aes))) and abusing the way the kernel splices pages into a scratch buffer, an unprivileged local user can write arbitrary 4-byte chunks directly into the page cache of files they should have no permission to modify - including SUID binaries like /usr/bin/su.

Once the page cache copy of su has been overwritten with a tiny malicious ELF, the next invocation runs the attacker's code as UID 0. Game over for the host.

For the gritty technical details (shellcode disassembly, syscall traces, the lot), Andrea Veri's writeup is excellent: CVE-2026-31431: Copy Fail vs. rootless containers. He also did the work of demonstrating - with eBPF and uid_map proofs - exactly what we'll talk about next: that user namespaces neutralise this exploit.

Why Appbox Apps Were Already Mitigated

The exploit relies on setuid(0) actually granting host root. In a container running with user namespaces enabled, that's not what happens.

User namespaces map the container's UID space to a different (unprivileged) UID range on the host. So when the exploit succeeds inside the container and setuid(0) returns success, the resulting "root" shell is mapped to a regular unprivileged host user - not real root. The shellcode runs, the prompt changes to #, but on the host:

podman     27943  0.0  0.0   2984  2028 pts/1    S+   22:15   0:00 sleep 100

That's it. No host file access, no /etc/shadow, no host root. The container's namespace boundary stops this from becoming a host-root escape.

At the platform level, each Appbox gets its own Docker daemon started with user namespace remapping enabled. In pseudocode, it looks more like this:

start_docker_daemon(
  userns_remap = appbox_id,
  container_namespace = appbox_id
)

That mapping is backed by a dedicated subordinate UID/GID range on the host:

write "/etc/subuid" -> "<appbox-id>:<host-subuid-start>:65536"
write "/etc/subgid" -> "<appbox-id>:<host-subgid-start>:65536"

On top of that, app definitions can still explicitly override UsernsMode when an app needs special handling:

container_config = {
  userns_mode: app.userns_mode,
  network_mode: app.network_mode,
  ...
}

So the accurate way to describe it is: user namespace remapping is part of the platform default, and per-app exceptions are explicit. There are a small number of apps that need different settings because they expose functionality that requires additional capabilities, and those cases are handled separately.

In other words: for apps running with the normal remapped setup, Copy Fail could not turn a container compromise into host root.

What We Still Wanted To Fix

User namespaces stop the host escape, but they don't make the bug go away inside the container. An attacker could still escalate to "container root" within the app boundary, which, while contained, is still bad housekeeping. The kernel itself was vulnerable, and we wanted that gone.

Once we found out about the bug, we immediately started assessing our exposure. Even though user namespace remapping already blocked the host-escape side of the issue for our normal app setup, we still wanted the underlying kernel bug gone as quickly as possible.

What We Did Yesterday

On Sunday night we scheduled emergency maintenance for Monday, May 4, 2026, the earliest window we could roll out a fleet-wide kernel upgrade.

During the window:

• Every host was upgraded using the official Debian kernel packages containing the "Copy Fail" fix.
• The goal was simple: remove the vulnerable kernel path entirely, not just rely on our existing namespace isolation.

Maintenance is complete. Every Appbox host is now running a patched kernel.

What This Means for You

• You didn't need to do anything. Your apps continued running and any brief blips during the maintenance window were the only customer-visible effect.
• Even before yesterday's patch, user namespace remapping meant this bug could not turn a normal app compromise into host root. That's exactly the kind of scenario this isolation model exists for.
• Going forward, our policy is unchanged: user namespaces stay on by default, and the very few exceptions go through extra security review.

The Bigger Picture

This is one of those CVEs where the headline ("local privilege escalation, public exploit, every modern kernel affected") sounds catastrophic, and for plenty of shared-tenant environments it really was. The reason it wasn't catastrophic for us is the same reason we made architectural decisions years ago that occasionally cost us a bit of compatibility: we run apps with the principle of least privilege baked into the container layer, not bolted on after the fact.

Defence in depth genuinely works. Bug at the kernel layer? The namespace layer caught it. Bug at the namespace layer? Capability drops and seccomp catch most of it. We don't pretend any single layer is perfect, we just make sure there's always a next one.

If you have any questions about this, or about how your specific apps are configured, please reach out.

Got questions? Contact us at support@appbox.co or open a ticket at billing.appbox.co.