Security Update: CVE-2026-31431 ("Copy Fail")

What happened

On April 29, 2026, CVE-2026-31431 ("Copy Fail") was publicly disclosed. The vulnerability is in the Linux kernel's authencesn AEAD cryptographic template, reachable from userspace through the AF_ALG socket interface (algif_aead). An unprivileged process can use it to perform a deterministic, controlled write into the kernel page cache, the in-memory representation of files on the system, without modifying anything on disk. The disclosure demonstrates the primitive can be used for local privilege escalation.

This advisory covers how the vulnerability affected Daytona's infrastructure and what we did about it.

Our infrastructure context

Daytona runs sandboxes on dedicated runner hosts. At the time of disclosure we were already migrating the runner fleet to a newer kernel generation as part of planned infrastructure work. Some runners had completed the migration; the rest were still on an affected kernel.

Within 12 hours of disclosure all unpatched runners were remediated: kernel patches where available, and algif_aead module blacklisting on the host as an immediate mitigation consistent with upstream guidance. Either measure makes the vulnerable primitive unreachable on the runner regardless of what runs inside a sandbox.

Scope of exposure

What the vulnerability allows. An unprivileged process able to open AF_ALG sockets can corrupt the in-memory content of cached files on the host kernel. On a host shared by multiple tenants, that creates a path for one sandbox to affect cached file content visible to co-tenant sandboxes through shared kernel memory.

What our internal assessment showed. During remediation we validated the impact against our own infrastructure. Before remediation the corruption primitive was reachable from inside a Daytona sandbox, and on runners hosting more than one tenant it could affect cached content observable to co-tenant sandboxes on the same runner. We did not observe a sandbox escape to the underlying runner host. The Sysbox runtime boundary itself was not breached in our testing. We are not publishing exploitation specifics. We treated the finding as critical and remediated all affected runners within 12 hours of public disclosure.

What we found in practice. Review of telemetry and audit logs across the affected window found no evidence the vulnerability was exploited against Daytona infrastructure by any party. The corruption primitive requires deliberate, targeted use; it does not execute automatically or passively affect sandbox workloads. We will update this advisory if that assessment changes.

Precautionary measures

Runner credential rotation. Runners hold scoped, least-privilege credentials to the Daytona control plane API. A runner can only perform operations needed to manage the sandboxes assigned to it; it cannot access tenant data, read sandbox contents, or perform administrative actions outside its scope. After disclosure we rotated all API credentials associated with runner infrastructure. Existing credentials were invalidated and replaced. This was precautionary, not a response to any observed compromise.

Signup pause during the response window. Between public disclosure and completion of fleet-wide remediation we paused all new user and organization signups. That closed off any opportunity for an attacker to create a fresh tenant to exploit the disclosure window. Existing customers were not affected; signups resumed once the fleet was fully patched.

What you need to do

Daytona infrastructure is fully remediated. No action is required to restore protection. Customer data on persistent volumes was not in scope of this vulnerability: the corruption primitive operates on transient kernel page cache, not on disk-persisted state.

Isolation is the foundation of what Daytona provides. When a vulnerability has the potential to affect sandbox boundaries we treat it as critical, regardless of whether exploitation is observed. For questions, contact security@daytona.io.