How Cloudflare handled the Copy Fail Linux vulnerability

On April 29, 2026, a Linux kernel local privilege escalation vulnerability was publicly disclosed under the name Copy Fail, tracked as CVE-2026-31431. Cloudflare said its security and engineering teams began assessing the issue as soon as it became public, reviewing the exploit technique, checking exposure across its infrastructure, and validating whether existing behavioral detections could identify the pattern.

Cloudflare’s account of the incident says there was no customer impact, no customer data at risk, and no service disruption during the response. Those impact statements come from Cloudflare’s own post and have not been independently verified here, so the safer reading is that Cloudflare reported a contained response with no observed customer-facing effect.

The response is useful because Copy Fail was not just another patch-and-reboot story. It involved a kernel-level bug, a potentially broad Linux attack surface, a delay between mainline fixes and the relevant stable backport, and the operational challenge of protecting a very large fleet without breaking production workloads.

Why Copy Fail mattered

Copy Fail was a local privilege escalation vulnerability. That means an attacker would generally need some level of local code execution first, but if they had it, the vulnerability could be used to move from an unprivileged process to root privileges.

The vulnerability involved the Linux kernel’s AF_ALG socket interface and the kernel crypto API. In simple terms, AF_ALG lets userspace programs ask the kernel to perform cryptographic operations. The affected path involved authenticated encryption handling and the way data could be passed into the kernel through splice().

A key part of the exploit technique was the Linux page cache. The page cache is the operating system’s shared cache for file contents. If an attacker can influence cached pages for a sensitive binary, the effect can be more serious than a normal process-local memory corruption issue. In the Copy Fail scenario, the exploit described by researchers targeted cached pages of a setuid-root binary, then used a kernel crypto bug to cause a small out-of-bounds write.

Cloudflare summarized the attack as a controlled 4-byte write into the page cache. The default public exploit path reportedly targeted /usr/bin/su, a privileged binary commonly present on Linux distributions. By changing selected bytes in cached executable content and then executing the binary, an attacker could cause injected code to run with elevated privileges.

That combination made the issue operationally urgent even if exploitation required local access. The vulnerable code path was in the kernel, the primitive was precise enough to be useful, and the affected component could exist broadly across Linux systems.

How Cloudflare’s kernel process shaped the response

Cloudflare operates Linux servers across a very large global edge network. The company says it maintains custom Linux kernel builds based on Long-Term Support releases, but the exact internal version distribution and rollout state are Cloudflare-reported details rather than independently confirmed facts.

According to Cloudflare, its normal process is built around recurring kernel updates, staging validation, and controlled fleet reboots. New internal kernel builds are generated from upstream stable updates, tested in staging data centers, and then rolled out through an edge reboot process over a multi-week cycle. Control plane systems follow their own scheduling based on workload needs.

That process matters because Linux security fixes are often merged upstream before a CVE becomes widely discussed. In many cases, a company with disciplined kernel update practices may already have the relevant fix before public disclosure. Copy Fail was more complicated. Cloudflare said the mainline fix existed earlier, but the backport for the kernel line used by much of its fleet was not available until later.

The result was a familiar infrastructure security problem: the company needed to protect systems immediately, but a complete patched-kernel rollout still required testing, staged deployment, and reboots.

What the exploit path looked like

The exploit described in Cloudflare’s write-up followed a sequence that combined AF_ALG, splice(), page cache behavior, and a privileged target binary.

At a high level, the public exploit flow worked like this:

1. An attacker opens a target setuid binary, such as /usr/bin/su, and reads it so that its contents are loaded into the page cache.
2. The attacker creates an AF_ALG socket and binds it to the affected authenticated encryption construction.
3. The attacker uses splice() to pass file-backed page references into the crypto operation path.
4. The attacker controls parameters that influence where a small out-of-bounds write lands.
5. The kernel crypto operation returns an error, but the write has already affected the cached target page.
6. The attacker executes the setuid binary, causing the modified cached content to run with elevated privileges.

The important point for defenders is that the exploit did not need to replace a file on disk in the usual way. It manipulated cached file contents through a kernel path. That makes ordinary file-write monitoring a less complete defense, and it explains why Cloudflare emphasized behavioral detection, kernel logs, and runtime mitigation instead of only package integrity checks.

Cloudflare also noted that the upstream fix reverted an earlier in-place crypto optimization. The practical effect of that fix was to remove the exploitable behavior rather than merely detect it after the fact.

Cloudflare’s immediate response workstreams

Once Copy Fail was disclosed, Cloudflare described several workstreams running in parallel. That is the right model for a kernel privilege escalation issue: waiting for one team to finish before another begins wastes time.

The major response tracks were:

• Mapping vulnerable kernel versions and determining which systems might be exposed.
• Reviewing the exploit technique closely enough to understand the real attack path.
• Validating whether existing endpoint and behavioral detections could identify exploitation.
• Searching historical logs for possible exploitation before public disclosure.
• Building a runtime mitigation that did not require an immediate reboot.
• Preparing, testing, and rolling out patched kernels once the needed backport became available.

Cloudflare’s stated impact assessment remained consistent throughout the post: the company reported no customer-facing disruption and no evidence of customer data exposure. Because those are internal findings, they should be treated as Cloudflare’s reported assessment rather than an independently audited conclusion.

Detection came before vulnerability-specific rules

One of the more useful parts of the response was Cloudflare’s discussion of detection coverage. The company said its servers already ran behavioral detection that monitored process execution patterns across the fleet. That detection was not written specifically for Copy Fail.

During internal validation, Cloudflare said the detection platform flagged the exploit chain within minutes. The company described the chain as beginning with a script interpreter, moving through the kernel cryptographic subsystem, and ending at a privilege escalation binary. The value of that approach is that it looks for suspicious behavior around execution and privilege boundaries rather than depending entirely on a known CVE signature.

That distinction matters for buyers and security teams evaluating endpoint detection. A vulnerability-specific rule is useful, but it arrives after someone understands the bug well enough to write it. Behavioral detection can sometimes provide earlier coverage, especially when the exploit produces unusual process relationships or privilege transitions.

It is also not a complete substitute for patching. In this case, detection helped Cloudflare gain confidence while engineering teams worked on mitigation and kernel updates. It did not remove the need to close the vulnerable path.

Threat hunting after disclosure

Cloudflare said its investigation followed a conservative operating principle: treat critical vulnerabilities as if compromise may have happened until evidence says otherwise. For Copy Fail, that meant looking backward, not only watching forward.

The company searched centralized logs for traces associated with the exploit, covering the 48 hours before public disclosure. It also reviewed access logs for affected systems, reconstructed interactive activity, checked system binaries against known-good package manifests, looked for persistence mechanisms, and audited network connections for unusual behavior.

Cloudflare reported that this investigation found no evidence of malicious exploitation. Again, that is Cloudflare’s own conclusion, but the methodology described is the part security teams can reuse: combine exploit-specific traces with broader compromise checks. A kernel exploit may leave one obvious signal, but a real intrusion often leaves secondary evidence in authentication logs, process history, persistence locations, or outbound connections.

Why removing the module was not enough

The vulnerable code was associated with the algif_aead kernel module. The simplest mitigation would have been to remove that module and prevent it from being reloaded. The public vulnerability write-up also recommended disabling the affected path where possible.

Cloudflare found that this direct approach was too blunt for its environment. Some production software depended on the kernel crypto API, so removing the module outright risked breaking legitimate workloads. The useful lesson is that a technically clean mitigation can still be operationally unsafe if it ignores real dependency paths.

That forced Cloudflare to find a narrower control: block untrusted access to the risky interface while allowing known legitimate users to continue working.

The no-reboot mitigation: BPF LSM

Cloudflare used BPF LSM as a runtime mitigation. BPF LSM lets teams attach policy logic to Linux Security Module hooks. Instead of unloading the module, Cloudflare used a BPF program to deny socket_bind access for the affected AF_ALG path except for allow-listed binaries.

The logic was deliberately simple:

• If the socket family was not AF_ALG, allow the bind operation.
• If the socket family was AF_ALG, check the calling binary against an allow-list.
• If the binary was approved, allow the operation.
• If the binary was not approved, deny the bind.

That blocked the front door used by the exploit while preserving access for known production software. It also avoided the immediate need to reboot every affected machine before protection could be in place.

This is the sort of control that is most valuable when the vulnerable path is narrow and the legitimate user base is small. It would be harder to apply safely if many unrelated services depended on AF_ALG, or if the allow-list could not be defined with confidence.

Visibility first, enforcement second

Cloudflare did not immediately enforce the BPF LSM policy everywhere. First, it measured AF_ALG usage across the fleet.

The company used prometheus-ebpf-exporter to observe socket creation and attribute AF_ALG usage to binaries. That gave engineering and security teams data about which programs were actually using the interface. Cloudflare said the results confirmed that the known internal service was effectively the only legitimate user.

Only after that visibility step did the company move to enforcement. The rollout had two stages:

1. Deploy eBPF-based visibility, gated through configuration, and confirm which binaries used AF_ALG.
2. Deploy the BPF LSM enforcement program behind a separate gate once the allow-list was validated.

That sequence reduced the risk of a mitigation-caused outage. It also created a cleaner rollback path: visibility could be expanded, enforcement could be staged, and production impact could be monitored before the policy reached the whole fleet.

Patched kernels still mattered

Runtime mitigation reduced the immediate risk, but it was not the final fix. Cloudflare continued preparing patched kernels in parallel. Once the relevant upstream backport became available for its main kernel line, internal automation built a patched kernel, staging validation began, and the longer reboot-based rollout resumed.

This is an important distinction. BPF LSM was a protective control around the vulnerable interface. The patched kernel removed the underlying vulnerability. For a critical kernel issue, the permanent answer is still to update the kernel, even when a runtime mitigation is strong enough to buy time.

Cloudflare said that by the end of the rollout, every machine in its fleet was protected by either a patched kernel or a BPF LSM program denying the vulnerable path to non-allow-listed binaries.

What security teams can take from the response

The Copy Fail response highlights several practical lessons for infrastructure and security teams.

First, kernel patching programs need more than a regular cadence. A recurring update cycle is necessary, but teams also need a plan for the gap between disclosure and full reboot coverage. Large fleets cannot always move instantly, especially when kernel updates require staged validation.

Second, runtime mitigation tools are most useful when they are already deployed and understood. Cloudflare was able to use BPF LSM because it had already developed the capability for this kind of scenario. Building that machinery during a live incident would have been much harder.

Third, visibility into kernel API dependencies matters. Cloudflare initially considered removing the affected module, then discovered that legitimate software depended on it. Better dependency visibility makes it easier to choose a narrow mitigation quickly.

Fourth, behavioral detection and threat hunting should support, not replace, engineering remediation. Detection helped Cloudflare validate coverage and search for abuse. Engineering controls and patched kernels closed the exposure.

Follow-up work Cloudflare identified

Cloudflare’s post ended with several improvement areas. The company said it plans to review production use of kernel subsystems, improve the speed and visibility of BPF LSM-based mitigation, and continue reducing Linux kernel attack surface by auditing unused modules and features.

Those follow-ups are grounded in the main operational friction points from the incident:

• Knowing which production services depend on specific kernel APIs.
• Deploying runtime mitigations quickly without breaking legitimate workloads.
• Improving logging and playbooks around emergency kernel controls.
• Removing unnecessary kernel features before they become emergency exposure.

For buyers evaluating cloud and infrastructure providers, this is the part worth watching over time. The immediate incident response matters, but the longer-term value is whether the provider turns the incident into better asset knowledge, faster mitigation paths, and a smaller attack surface.

The bottom line

Copy Fail was a serious Linux kernel privilege escalation issue because it combined an accessible kernel crypto interface with page cache manipulation and a practical path to root privileges. Cloudflare’s reported response combined detection validation, retrospective threat hunting, a no-reboot BPF LSM mitigation, and a patched-kernel rollout.

The strongest part of the response was not any single tool. It was the parallel handling: security teams investigated and hunted, kernel engineers worked on mitigation, observability was used before enforcement, and patch deployment continued in the background.

Cloudflare reported no customer impact and no evidence of malicious exploitation in its environment. Those claims depend on Cloudflare’s internal telemetry and investigation, but the response model is still instructive: for critical kernel vulnerabilities, mature operations need detection, fleet visibility, emergency runtime controls, and disciplined patching working at the same time.