Hunt Copy Fail Before CISA's Tomorrow Deadline: Four Microsoft Defender Signatures, a Falco Rule for Containers, and a Tracepoint Probe That Catches the Rest.

The patch is the durable fix. Reboot the kernel, move on. This post is for the operators who cannot get a reboot window scheduled before CISA's federal deadline tomorrow, who need to know if anything is already moving against them, and who want a layered detection posture for the gap.

Copy Fail (CVE-2026-31431) is a use-after-free in the Linux kernel's AF_ALG cryptographic socket subsystem, specifically the algif_aead module. The exploit path is small: the attacker opens an AF_ALG socket bound to algif_aead, then triggers a splice() syscall that fails in a specific way during the in-place copy optimization. The failed copy leaves the page cache holding a reference to memory the calling process has already freed. From there, primitive promotion to arbitrary kernel write, primitive promotion to root.

The behavioral signature is what makes this detectable in the absence of a specific exploit binary on disk. Production application traffic almost never opens AF_ALG sockets. The userspace crypto API exists for a narrow set of use cases — disk encryption tooling, some VPN clients, a handful of cryptocurrency wallets, kernel-level keyring operations. Outside those, an AF_ALG socket creation paired with a splice() syscall in the same process is anomalous to the point of being a near-perfect indicator. That is the behavior every detection layer below keys on.

Layer one is Microsoft Defender XDR. If you run Defender for Endpoint on Linux, four signatures fire on this CVE family. Exploit:Linux/CopyFailExpDl.A catches the downloader stage of staged exploit kits that pull the 732-byte payload after initial access. Exploit:Python/CopyFail.A catches the original Python proof-of-concept that started circulating publicly on May 1. Exploit:Linux/CVE-2026-31431.A is the specific CVE detection covering Go and Rust ports that have already shown up on open-source repositories. Behavior:Linux/CVE-2026-31431 is the runtime behavioral detection — this is the one that catches future ports we have not seen yet, because it watches the syscall pattern rather than file hashes. Surface all four in your alerting. The KQL pattern for hunting them in Microsoft Sentinel is straightforward: query DeviceEvents where ActionType has "Exploit" and AdditionalFields contains "CVE-2026-31431" or contains "CopyFail" — that catches both name variants Defender uses across the four signatures.

Layer two is Falco for Kubernetes and Docker workloads. Falco ships with a rule called "Unexpected socket family" that already covers AF_ALG socket creation when paired with the right macro. The rule you want enabled in your falco-rules.yaml is one that triggers on syscall socket where family equals AF_ALG (numeric value 38) and the process is not in your allowlist of expected AF_ALG users. The output line should include the process name, container ID, command line, parent process, and pod identity. Tag it with priority WARNING because the false-positive rate on this signal is genuinely low — production applications calling AF_ALG outside the narrow allowlist named above is itself worth a human look. Falco also lets you write a follow-on rule that pairs the AF_ALG socket creation with a splice() syscall in the same process within a short window, which gets you closer to the actual exploitation behavior and almost zero false positives.

Layer three is eBPF for hosts that run neither Defender nor Falco, or as a complementary signal for hosts that do. The probe is shorter than most people expect — attach a tracepoint to syscalls:sys_enter_socket, filter on the family argument equal to AF_ALG (38), and emit the process ID, command name, and parent PID into a perf buffer. Twelve lines of bpftrace, roughly. The companion probe attaches to syscalls:sys_enter_splice with the same process ID correlation. Pair them with a short window and you have a behavioral detector that runs at native syscall speed and emits one line per suspicious pairing. The bpftrace one-liner is small enough to deploy via a configuration management push to every Linux host in your fleet inside an hour, and the output can be shipped to your SIEM via standard syslog forwarding.

The hunt for what may already be sitting in your environment runs against logs, not live probes. If you have any of these data sources retained for the last fourteen days — auditd records, sysmon for Linux, Defender device events, Falco events shipped to a SIEM, or eBPF observability tooling like Sysdig or Tetragon — search for socket() syscalls with AF_ALG family in any process not in your allowlist. The allowlist of expected AF_ALG users is short and your security team should be able to enumerate it in five minutes by asking the platform owners. Anything outside that allowlist in the last fourteen days deserves a follow-up: confirm patch status of the host, confirm the process did not also execute splice() in the same session, and check for downstream privilege-elevation indicators like a setuid binary execution, a new user account, or an SSH key written to a system account home directory. Those are the post-exploitation breadcrumbs that survive even when the exploit binary itself is wiped from disk.

The mitigation if you cannot patch the kernel before the weekend is to disable AF_ALG entirely at the module level. The vast majority of production workloads do not use the userspace crypto API. Blacklist the algif_aead module by adding the line "blacklist algif_aead" to a file in /etc/modprobe.d, run update-initramfs and a reboot, and the attack surface goes to zero. For containerized workloads where you cannot modify the host kernel, the seccomp profile change is to deny socket() syscalls with family equal to AF_ALG at the container runtime. Both docker run and Kubernetes pod security policies accept seccomp profiles that scope the denied syscalls per container. The operational impact of denying AF_ALG access from inside containers is almost always zero — the workloads that need userspace crypto are not the ones running in standard application containers anyway.

The cleanest signal that your detection stack is actually wired correctly is to run the test yourself. The Linux kernel ships a small AF_ALG test program in the upstream tools directory under tools/crypto. Build it on a test host that has your detection stack attached, run it once with a benign aead operation, and confirm that Defender or Falco or your eBPF probe emits the expected event. If nothing fires, your stack is not wired up the way you think it is. That five-minute test is the difference between actually having detection coverage and assuming you do.

What to do if a real hit shows up in the hunt. The behavioral signature alone does not prove exploitation — it proves an unusual code path. Confirm by checking whether the same process executed splice() within the same session, whether root-owned files were modified in the minutes after the AF_ALG socket creation, and whether outbound network connections to unfamiliar destinations originated from the host in the same window. If all three are present, treat it as an active compromise and isolate the host. The kernel exploitation primitive is durable enough that a reboot does not necessarily evict an attacker who has already established persistence at higher layers — assume credential theft, key extraction from the kernel keyring, and lateral movement attempts before the alert fired.

Tomorrow is the federal deadline. The patch shipped weeks ago in kernel 6.18.22, 6.19.12, and 7.0. The detection stack above buys time for the operators who cannot get a reboot window in the next twenty-four hours and gives the operators who can a way to confirm they were not already touched. Both are reasonable positions to be in the day before a CISA KEV deadline. The unreasonable position is the one where you have neither patched the host nor instrumented the syscall pattern. That is the gap an attacker who has been reading the same CISA alert you have been reading is counting on.

Sources: Microsoft Security Blog CVE-2026-31431 writeup, May 1 2026. CISA Known Exploited Vulnerabilities Catalog entry, May 1 2026. The Linux kernel AF_ALG documentation at kernel.org. Falco syscall coverage documentation at falco.org. The bpftrace one-liner tutorial for tracepoint:syscalls.

---

How do AI models see YOUR brand?

AIPM has audited 250+ domains. 15 seconds. Free while still in beta.

Audit your site now → aipmsec.com