The 732-Byte Wake-Up Call

Security is not a phase you pass through on the way to production. It is a permanent condition.

On April 29, 2026, a security research team published a vulnerability that works on every Linux distribution shipped since 2017. Not most. Every. The exploit is a single Python script. It is 732 bytes long. It requires no race conditions, no kernel-specific offsets, no special privileges beyond a local user account. One script, every distro, every time. They called it Copy Fail [1].

Three weeks earlier, on April 7, Anthropic announced Claude Mythos Preview, a model that had autonomously discovered a 27-year-old bug in OpenBSD, a 16-year-old bug in FFmpeg, and a 17-year-old remote code execution vulnerability in FreeBSD. It found thousands more [4]. The timing is not a coincidence. Copy Fail is the kind of bug that AI-driven vulnerability discovery was built to find, and it arrives at exactly the right moment to show what that means in practice.

As someone who works with cloud customers running Linux everywhere (EC2 instances, EKS clusters, Lambda runtimes, container hosts, CI/CD runners), this hit close to home. Every one of those systems was vulnerable. Some still are.

The Bug: A Beautiful Logic Flaw

Copy Fail is, in the words of the Low Level YouTube channel, “one of the most beautiful exploits I have seen in a very long time” [1]. That is not hyperbole. The exploit chains together three perfectly legitimate kernel interfaces in a way nobody anticipated for nine years. To understand why it works, we need to walk through the Linux kernel’s plumbing.

Linux Sockets and the AF_ALG Interface

In Linux, everything is a file. Sockets are files. There are different kinds of sockets for different purposes: TCP and UDP for network communication, Unix sockets for inter-process communication on the same machine, and a less well-known family called AF_ALG [1] [3].

AF_ALG lets userspace programs access the kernel’s built-in cryptographic algorithms. This is actually good practice. You should not roll your own crypto. The kernel has vetted implementations, and it may have access to hardware accelerators: physical circuits inside the CPU that can perform cryptographic operations faster than software [1].

AF_ALG ships enabled in essentially every mainstream distribution’s default kernel configuration. It has since 2017 [3].

Scatter-Gather Lists: How the Kernel Tracks Data

Every socket in the kernel maintains two important data structures: an input scatter list and an output scatter list. A scatter list is a linked list of entries, each pointing to a physical memory page with an offset and a length [1].

Why scatter lists? When you send 40,000 bytes through a socket, those bytes do not sit in one contiguous block of physical memory. They are scattered across roughly ten physical pages of varying sizes. The scatter list tells the kernel where to find each piece [1].

When you send data via sendmsg(), the kernel populates the input scatter list with references to the pages containing your data. For the output, the kernel allocates fresh pages. When you read from the socket, you get the contents of the output scatter list. Input is read-only from the kernel’s perspective. Output is where results go. That separation matters enormously [1].

AEAD: Authenticated Encryption with Associated Data

Among the algorithms AF_ALG exposes is a family called AEAD — Authenticated Encryption with Associated Data. AEAD combines two properties: encryption (nobody can read the data) and authentication (you can verify who sent it). The authentication piece uses an HMAC — a hash-based message authentication code — which acts as a cryptographic signature [1].

The kernel expects AEAD data in a specific order:

1. AAD — Associated Authenticated Data (metadata that is authenticated but not encrypted)
2. Cipher Text — the encrypted payload
3. Tags — the HMAC signature, the authentication piece

When you call sendmsg() with this data, it populates the input scatter list. The AAD and cipher text land on their pages. The tags land on a separate page. The kernel then allocates new pages for the output scatter list and runs the crypto algorithm [1].

The 2017 Optimization That Broke Everything

In August 2017, a kernel commit introduced a performance optimization. Instead of allocating entirely new output pages for the crypto operation, the kernel would reuse the tags page from the input scatter list as part of the output. The input and output scatter lists were made to point to the same underlying pages, an in-place operation [3] [5] [10].

Before the optimization, the three AEAD inputs (AAD, cipher text, tags) lived on read-only input pages, and the kernel allocated separate output pages for the result. After the optimization, the tags page served double duty: it was both an input page and an output target.

For most algorithms, this is fine. The crypto runs, writes its output, and everyone is happy.

But there is one particular algorithm used in IPsec called authencesn — authenticated encryption with extended sequence numbers. Extended sequence numbers are 64-bit values that track packet ordering in IPsec connections. To compute the HMAC for a packet, the authencesn algorithm temporarily writes four bytes of signature data to the tags page as a scratchpad. It uses the old signature location as temporary working space before writing the final result [1] [3].

The key insight: after the 2017 optimization, the tags page is no longer guaranteed to be a kernel-allocated crypto buffer. If an attacker can control which page ends up in the tags position of the input scatter list, those four scratchpad bytes land wherever the attacker wants.

Under normal circumstances, this is harmless. The scratchpad write lands on a page that contains crypto data anyway. Nobody outside the kernel cares about the intermediate state of an HMAC computation.

Unless that page is not actually a crypto page.

The splice() Trick: Where It Gets Brilliant

Here is where the exploit turns from a kernel internals curiosity into something devastating.

Instead of sending all three components (AAD, cipher text, and tags) via sendmsg(), the attacker sends only the AAD and cipher text. The tags page is left empty in the input scatter list. Then the attacker calls splice() [1] [3].

splice() is a system call that takes data from one file descriptor and pipes it into another. In this case, into the crypto socket. What splice() does under the hood is append a new page to the input scatter list. But this page is not a freshly allocated buffer. It is the page cache entry for whatever file the attacker opened [1].

The page cache is how Linux avoids reading files from disk repeatedly. When you open /usr/bin/su, the kernel loads its contents into memory and keeps them cached. Every subsequent read of that file, by any process on the system, reads from the cache, not from disk.

So now the input scatter list looks like this: AAD pages, cipher text pages, and then the page cache page of /usr/bin/su. The kernel’s in-place optimization has made the output scatter list point to the same pages. When the authencesn algorithm runs, it writes its four-byte scratchpad to what it thinks is the tags page. But that page is actually the cached copy of /usr/bin/su [1] [3].

And splice() accepts an offset parameter. The attacker controls exactly where in the binary those four bytes land. Write four bytes at offset 0. Four bytes at offset 4. Four bytes at offset 8. Repeat until you have overwritten enough of the cached binary with shellcode [1].

The Kill Shot

The final step is trivial. The attacker calls execve() on /usr/bin/su. The kernel does not reload the binary from disk. It already has a cached copy in memory. The kernel still sees su as a setuid-root binary. It runs the attacker’s shellcode as root [1] [3].

The on-disk file is unchanged. File integrity monitoring tools that check disk contents will not catch it. The corruption exists only in the page cache, the version of the file that every process on the system actually reads and executes [3] [9].

Here is the beautified exploit. The original is deliberately obfuscated, but the logic is clear:

import os, socket, zlib

# 1. Open AF_ALG socket, bind to authencesn algorithm
sock = socket.socket(socket.AF_ALG, socket.SOCK_SEQPACKET, 0)
sock.bind(("aead", "authencesn(hmac(sha256),cbc(aes))"))
sock.setsockopt(socket.SOL_ALG, socket.ALG_SET_KEY, bytes(20))

# 2. Accept operation socket
op, _ = sock.accept()

# 3. For each 4-byte chunk of shellcode:
#    - sendmsg() with AAD + ciphertext
#    - splice() the target binary's page cache page
#    - recvmsg() triggers the crypto write
#    The 4 controlled bytes land at the chosen offset
#    in /usr/bin/su's page cache

# 4. execve("/usr/bin/su") — runs the corrupted cached version as root
os.execv("/usr/bin/su", ["/usr/bin/su"])

732 bytes. That is the entire exploit.

Why This Bug Is Special

Linux privilege escalation vulnerabilities are not new. But Copy Fail is in a different category from its predecessors.

Copy Fail is a pure logic flaw. There is no race to win. There are no kernel-specific offsets to calculate. There is no heap spray, no ASLR bypass, no ROP chain. The exploit uses four standard system calls (socket(), setsockopt(), splice(), sendmsg()) in a sequence that the kernel handles deterministically. First try, every time, every distribution [1] [3].

The researchers at Theori verified it on Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1, and SUSE 16. Other distributions running affected kernels (Debian, Arch, Fedora, Rocky, Alma, Oracle) behave the same [3].

The Impact: From Laptops to Kubernetes Clusters

CISA added CVE-2026-31431 to the Known Exploited Vulnerabilities catalog on May 1, 2026, following evidence of active exploitation in the wild. Federal civilian agencies now have a May 15 deadline to patch [6]. Microsoft Defender reported preliminary testing activity, proof-of-concept probing that typically precedes broader exploitation campaigns [7].

Go and Rust reimplementations of the exploit appeared within days of disclosure [8]. The 732-byte Python script was already trivial to deploy, but compiled versions eliminate the Python dependency entirely.

Kubernetes: The Page Cache Problem

The page cache is shared across the entire host. It is not namespaced. It is not isolated per container. Every pod on a Kubernetes node shares the same kernel and the same page cache [9].

Juliet Security tested Copy Fail on two real Kubernetes clusters, Talos with containerd and EKS on Amazon Linux 2023. Their findings [9]:

• Pod Security Standards Restricted did not block it. A non-root pod with all capabilities dropped could create AF_ALG sockets and bind the authencesn algorithm.
• RuntimeDefault seccomp did not block it. The default seccomp profiles for Docker/Moby and containerd deny AF_VSOCK (address family 40) but do not deny AF_ALG (address family 38).
• Cross-pod page cache visibility was confirmed. A writer pod in one namespace changed cached bytes of a file baked into a container image layer. A reader pod from the same image on the same node observed the changed bytes.
• Container root was achievable. When a pod with allowPrivilegeEscalation: true consumed a mutated setuid binary from a shared image layer, it reached euid 0.

The finding that matters most: this is not limited to hostPath mounts. A file baked into a container image layer was enough. The claim “this only matters if you mount hostPath” is not true [9].

Who Should Patch First

The priority list, roughly in order of urgency:

• Multi-tenant Linux hosts — shared dev boxes, jump hosts, build servers. Any user becomes root.
• Kubernetes clusters — the page cache is shared across the host. Cross-container, cross-tenant.
• CI/CD runners — GitHub Actions self-hosted runners, GitLab runners, Jenkins agents. A pull request becomes root on the runner.
• Cloud SaaS running user code — notebook hosts, agent sandboxes, serverless functions, any tenant-supplied container.
• Standard Linux servers — single-tenant production where only your team has shell access. Lower priority, but still an internal privilege escalation that chains with any web RCE or stolen credentials.

Enter Claude Mythos: AI Finds What Humans Missed

Copy Fail sat in the Linux kernel for nine years. Thousands of developers, security researchers, and automated fuzzers looked at the crypto/ subsystem during that time. Nobody found it.

On April 7, 2026, three weeks before Copy Fail’s public disclosure, Anthropic published a detailed technical assessment of Claude Mythos Preview’s cybersecurity capabilities [4]. The full report runs to thousands of words of technical evidence. But the headline numbers tell the story.

The Scale of Discovery

Mythos Preview found a 27-year-old bug in OpenBSD’s TCP SACK implementation. OpenBSD — an operating system whose first five words on Wikipedia are “OpenBSD is a security-focused.” The bug involved a signed integer overflow in sequence number comparison that could crash any OpenBSD host responding over TCP. The specific run that found it cost under $50 in API tokens [4].

It found a 16-year-old vulnerability in FFmpeg’s H.264 codec. FFmpeg is one of the most thoroughly fuzzed software projects in the world. Entire research papers have been written about how to fuzz media libraries like FFmpeg. The bug had been missed by every fuzzer and every human reviewer since 2010 [4].

It found a 17-year-old remote code execution vulnerability in FreeBSD’s NFS server (CVE-2026-4747). Fully autonomous — no human involved after the initial prompt. The exploit was a 20-gadget ROP chain split across six sequential RPC packets that granted full root access to unauthenticated users anywhere on the internet [4].

The Benchmark Gap

Anthropic ran both Opus 4.6 and Mythos Preview against the same benchmark: turning known vulnerabilities in Firefox 147’s JavaScript engine into working exploits.

Opus 4.6 produced 2 working exploits out of several hundred attempts.

Mythos Preview produced 181 [4].

On their internal OSS-Fuzz benchmark — roughly 7,000 entry points across a thousand open source repositories — Opus 4.6 achieved a single crash at severity tier 3 (out of 5). Mythos Preview achieved full control flow hijack (tier 5) on ten separate, fully patched targets [4].

Non-experts at Anthropic with no formal security training asked Mythos Preview to find remote code execution vulnerabilities overnight. They woke up the next morning to complete, working exploits [4].

What Mythos Did Not Need

These capabilities were not explicitly trained. They emerged from general improvements in code understanding, reasoning, and autonomous operation. But the key point is not that Mythos is smart. It is that Mythos is thorough. It used well-understood primitives (JIT heap sprays, ROP chains, KASLR bypasses, cross-cache reclamation) and applied them to every file, every angle, without getting bored, without skipping the boring-looking code, without assuming “obviously someone would have checked that before” [4].

Copy Fail was found by Xint Code, which scanned the Linux crypto/ subsystem for about an hour [3]. The same scan surfaced other high-severity bugs still in coordinated disclosure. The pattern is the same: AI systems grinding through code with a diligence that humans cannot sustain.

The Equilibrium Is Shifting

Anthropic’s assessment includes a paragraph that I think every security professional should read:

“After navigating the transition to the Internet in the early 2000s, we have spent the last twenty years in a relatively stable security equilibrium. New attacks have emerged with new and more sophisticated techniques, but fundamentally, the attacks we see today are of the same shape as the attacks of 2006. But language models that can automatically identify and then exploit security vulnerabilities at large scale could upend this tenuous equilibrium.” [4]

That is not marketing. It is a sober assessment from the organization that built the model, published alongside thousands of words of technical evidence.

Here is what is changing.

Friction-Based Security Is a Depreciating Asset

Many defense-in-depth measures work not because they are theoretically unbreakable, but because breaking them is tedious. KASLR does not make kernel exploitation impossible; it makes it annoying. Stack canaries do not prevent all buffer overflows; they make exploitation require an additional step. Seccomp profiles do not eliminate attack surface; they make attackers work harder to find the right syscall sequence.

Against human attackers, tedium is a real defense. Humans get tired. They make mistakes under time pressure. They give up on the third failed attempt and move to an easier target.

AI does not get tired. Mythos Preview ground through KASLR bypasses, heap sprays, and multi-vulnerability chains that would take a skilled human researcher days to weeks. It did it in hours, for under $2,000 [4].

Mitigations that impose hard barriers (W^X, memory safety in new code, hardware-enforced isolation) remain important. Mitigations that rely primarily on friction are weakening [4].

N-Day Windows Are Collapsing

The N-day exploitation window, the time between a vulnerability being publicly disclosed and a working exploit appearing, has historically been measured in days to weeks. That window gave defenders time to patch.

Anthropic demonstrated that Mythos Preview can take a CVE identifier and a git commit hash and produce a fully functional privilege escalation exploit autonomously. The two detailed N-day exploits they published — a one-bit page-table write and a one-byte read turned into root under HARDENED_USERCOPY — were each completed in under a day for under $2,000 [4].

When exploit development takes hours instead of weeks, the patch-or-perish window shrinks to match.

Disclosure Volume Will Outpace Human Triage

Anthropic reported thousands of high- and critical-severity vulnerabilities found during their testing period. They contracted professional security firms to manually validate every bug report before disclosure. In 89% of the 198 manually reviewed reports, the human validators agreed with the model’s severity assessment exactly. 98% were within one severity level [4].

That validation pipeline is already a bottleneck. As models improve and more organizations deploy them for vulnerability scanning, the volume of legitimate disclosures will increase faster than human triage capacity can scale.

What Defenders Should Do Now

1. Patch Copy Fail Immediately

Update to a kernel version that includes mainline commit a664bf3d603d. This reverts the 2017 in-place optimization so that page-cache pages can no longer end up in the writable output scatter list [3].

If you cannot patch immediately, disable the algif_aead module:

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead

For the vast majority of systems, this breaks nothing. dm-crypt, LUKS, kTLS, IPsec, OpenSSL, and SSH do not use AF_ALG by default. The module is a userspace front door to kernel crypto that almost nothing actually uses [3].

One caveat: on some RHEL-family kernels, algif_aead is built into the kernel rather than loaded as a removable module. The modprobe.d blacklist and rmmod commands will run without error but will not actually remove the attack surface. Validate with a runtime AF_ALG bind test [9].

2. For Kubernetes: Deploy Custom Seccomp Profiles

RuntimeDefault does not block AF_ALG. PSS Restricted does not block AF_ALG. You need a custom Localhost seccomp profile that denies socket() when the first argument is address family 38 [9].

Do not block all socket() calls — that will break your workloads. The narrow control is to deny only AF_ALG socket creation. Apply it to namespaces running untrusted code: CI jobs, build runners, multi-tenant workloads, anything that executes customer-supplied code [9].

3. Shrink Patch Cycles

If N-day exploitation now takes hours instead of weeks, your patching cadence needs to match. Treat dependency bumps that carry CVE fixes as urgent, not routine maintenance. Enable auto-update where possible. Ship out-of-band releases for critical vulnerabilities rather than waiting for the next scheduled cycle [4].

4. Use Frontier Models for Defensive Scanning Now

You do not need access to Mythos Preview to start. Current frontier models find high- and critical-severity vulnerabilities almost everywhere they look. Anthropic found hundreds of vulnerabilities using Opus 4.6 alone — in OSS-Fuzz targets, web applications, crypto libraries, and the Linux kernel [4].

The scaffolding is simple: launch a container with the project under test, invoke the model with a prompt asking it to find security vulnerabilities, and let it experiment. The model reads code, hypothesizes vulnerabilities, runs the project to confirm or reject its suspicions, and outputs a bug report with reproduction steps [4].

Starting early matters. It takes time to learn how to use these tools effectively. The organizations that have built scaffolds and procedures with current models will be ready when models with Mythos-class capabilities become broadly available [4].

5. Automate Incident Response Triage

More disclosures mean more attacker attempts against the window between disclosure and patch. Most incident response programs cannot staff their way through that volume. Models should carry the technical work: triaging alerts, summarizing events, prioritizing what a human needs to look at, running proactive hunts in parallel with active investigations [4].

6. Treat Container Isolation as a Security Boundary

The Copy Fail Kubernetes findings are a reminder: containers on the same node share a kernel and a page cache. Namespace isolation does not extend to the page cache. If you are running multi-tenant workloads, CI/CD runners, or any workload that executes untrusted code, isolate it onto dedicated nodes. Consider sandboxed runtimes like gVisor or Kata Containers for high-risk workloads, but test them first [9].

AWS-Specific Mitigations

Note: The information below reflects the state as of early May 2026. AWS is actively rolling out patches. Check the Amazon Linux Security Center and your AWS account notifications for the latest guidance.

Amazon Linux: Kernel updates for Amazon Linux 2023 are rolling out. Check yum updateinfo list cves for CVE-2026-31431 availability on your instances. Apply as soon as available.

Amazon EKS: EKS nodes run on Amazon Linux and are affected. The Juliet Security team confirmed the vulnerability on EKS with Amazon Linux 2023 kernels [9]. Update your managed node groups and self-managed nodes as patches become available. For immediate mitigation, deploy a custom seccomp profile blocking AF_ALG (address family 38) to namespaces running untrusted workloads.

AWS Fargate and Lambda: These services use Firecracker microVMs, which provide a different isolation model than shared-kernel containers. Each Fargate task and Lambda invocation runs in its own microVM with a dedicated kernel. This architectural difference means the page-cache sharing attack path does not apply in the same way. However, the underlying kernel still needs patching, and AWS manages this transparently for Fargate and Lambda customers.

Amazon Bedrock and AI security scanning: Claude Mythos Preview is available on Amazon Bedrock as a gated research preview for defensive cybersecurity use cases [15]. For customers who want to start scanning their own codebases today, Claude Opus 4.7 (generally available on Bedrock) is already effective at finding high-severity vulnerabilities. Anthropic’s own testing found critical bugs using Opus 4.6 across OSS-Fuzz targets, web applications, and the Linux kernel [4].

The Bigger Picture

The 2017 optimization, the scratchpad write, and splice() were each individually defensible. The vulnerability existed only in their intersection, invisible for nine years.

In Security Is Job Zero [12], I argued that security agents should be permanent team members, not annual visitors. Copy Fail makes that argument concrete. A security agent scanning the crypto/ subsystem — the way Xint Code did — would have found this. Not in nine years. In hours.

In The Agent Security Stack [13], I wrote about the emerging security surface that AI agents create. Copy Fail flips that framing. AI agents are not just a new attack surface. They are the most powerful vulnerability discovery tool we have ever built. The question is whether defenders adopt them faster than attackers do.

Anthropic believes that in the long run, defense capabilities will dominate — that the world will emerge more secure, with software better hardened by code written by these models [4]. I think they are right. But they also acknowledge that the transitional period will be difficult. The advantage belongs to whichever side gets the most out of these tools first.

732 bytes. That is the distance between an unprivileged user and root on every Linux box shipped in the last nine years. The bug was there the whole time. It just needed someone — or something — patient enough to look.

When was the last time you ran a security scan that went beyond the obvious?

Sources

[1] Low Level: This Exploits LITERALLY Every Linux Distro

[2] CERT-EU Advisory 2026-005

[3] Xint / Theori: Copy Fail — CVE-2026-31431

[4] Anthropic: Assessing Claude Mythos Preview’s cybersecurity capabilities

[5] The Hacker News: New Linux Copy Fail Vulnerability

[6] CISA Adds CVE-2026-31431 to KEV

[7] Microsoft Defender: Copy Fail analysis

[8] Kaspersky: Copy Fail analysis

[9] Juliet Security: Copy Fail in Kubernetes

[10] The Register: Linux cryptographic code flaw

[11] Sysdig: CVE-2026-31431

[12] Security Is Job Zero

[13] The Agent Security Stack Nobody Is Building

[14] Wiz: Copy Fail CVE-2026-31431

[15] AWS: Amazon Bedrock Claude Mythos Preview

About the Author

Stefan Christoph is a Principal Solutions Architect at AWS, focused on agentic AI, media & entertainment, and helping builders move from demo to production. He writes about AI architecture, developer productivity, and the future of software.

This is a personal blog. Opinions expressed here are my own and do not represent the views or positions of my employer.

Learn more →

• Security
• Linux
• AI
• Cybersecurity
• CloudSecurity
• Kubernetes