Detecting copyfail (CVE-2026-31431) exploitation using eBPF

For years, Linux security and observability have relied on a patchwork of tools. We scraped user-space logs, parsed Auditd events, and heavily monitored network traffic. But as adversaries have grown more sophisticated, moving deeper into the system to exploit kernel-level vulnerabilities, traditional monitoring has started to show its age. It’s often too noisy, too slow, or simply blind to exactly what is happening in the dark corners of the operating system.

Enter eBPF (Extended Berkeley Packet Filter).

If you are defending Linux infrastructure today, eBPF isn’t just a buzzword—it is the undisputed future of observability and the prime real estate for detecting badness.

What Makes eBPF an excellent visibility tool?

At its core, eBPF allows developers to run sandboxed, highly efficient programs directly within the Linux kernel without requiring kernel source code modifications or loading dangerous custom kernel modules.

Think of it like JavaScript for the Linux kernel. Just as JS allows you to run scripts safely in a web browser to react to user clicks, eBPF allows you to run scripts safely in the kernel to react to system events.

For security teams, this provides three massive advantages:

1. Unprecedented Visibility: eBPF can hook into almost anything—system calls, network stacks, file system operations, and kernel tracepoints.
2. High Fidelity: Because you are inspecting events at the exact moment the kernel executes them, attackers cannot easily spoof or bypass the telemetry.
3. Low Overhead: eBPF programs are compiled Just-In-Time (JIT) and heavily verified by the kernel for safety, meaning they run with near-zero performance impact.

To understand exactly how powerful this is, let’s look at how eBPF enables high-fidelity detection of advanced local privilege escalation (LPE) techniques, specifically focusing on the AF_ALG socket.

Case Study: Detecting Cryptographic Abuse via AF_ALG

Recently, the security community has seen complex vulnerabilities (such as the “Copy Fail” LPE, CVE-2026-31431) that exploit the kernel’s cryptographic API. The entry point for these exploits is a specific type of socket connection known as AF_ALG.

What is AF_ALG?

AF_ALG (Address Family 38) is the user-space interface to the Linux kernel’s Crypto API. It allows a user-space program to ask the kernel to perform cryptographic operations (like AES encryption or SHA hashing) natively.

Under normal circumstances, standard user applications—like Python scripts, web servers, or bash shells—have absolutely no reason to create an AF_ALG socket. They handle cryptography in user-space using libraries like OpenSSL. The only tools that generally touch AF_ALG are specialized kernel-aware utilities.

Therefore, if a random bash shell or Python script suddenly opens an AF_ALG socket, it is a massive, glowing red flag that an exploit is attempting to manipulate kernel memory or trigger a page-cache poisoning vulnerability.

How eBPF Catches It

Traditional network monitoring won’t catch this because AF_ALG isn’t a network protocol; it never hits the wire. Standard process monitoring misses it because the process itself isn’t doing anything inherently malicious until the socket is already open and the payload is injected.

Here is a brief breakdown of how eBPF steps in to provide a high-fidelity detection:

1. The Hook: An eBPF security sensor attaches a tiny program to the kernel’s sys_exit_socket tracepoint. Every time any program on the system tries to create a socket, this eBPF program wakes up.
2. The Inspection: When the system call finishes, the eBPF program intercepts the arguments passed to the kernel. It looks specifically at the domain (or family) argument.
3. The Logic: The eBPF program runs a simple check: Did the process ask for family ID 38 (AF_ALG)? AND Is this process missing from our allowlist of known-good crypto utilities?
4. The Alert: If the answer is yes, the eBPF program instantly fires an alert to user-space. Because it operates at the kernel level, the alert contains the exact PID, the command line arguments (e.g., python3 exploit.py), the user ID, and the container context.

Putting It Into Practice: A Falco Detection Rule

To see what this looks like in the real world, we can use Falco, the open-source, eBPF-powered cloud-native runtime security project.

Because exploits relying on this vector must call socket(AF_ALG, ...) repeatedly to inject their payload into memory in small chunks, this rule will light up immediately, capturing every single attempt with zero chance of the attacker hiding the syscall from the kernel itself.

Here is a clean, modern Falco rule to detect this exact behavior:

- macro: expected_af_alg_processes
  desc: Exclude legitimate binaries that might use the kernel crypto API (tune as needed for your environment)
  condition: (proc.name in (kcapi-enc, kcapi-dgst, kcapi-mac))

- rule: Potential Copy Fail Exploit (AF_ALG Socket Creation)
  desc: >
    Detects the creation of an AF_ALG socket (family ID 38). This interface is the 
    primary vector for the Copy Fail (CVE-2026-31431) local privilege escalation vulnerability.
  condition: >
    evt.type = socket and 
    evt.arg.domain = AF_ALG and 
    evt.res >= 0 and
    not expected_af_alg_processes
  output: >
    Anomalous AF_ALG socket created (user=%user.name uid=%user.loginuid command=%proc.cmdline pid=%proc.pid container_id=%container.id image=%container.image.repository)
  priority: CRITICAL
  tags: [host, container, exploit, privilege_escalation, cve_2026_31431]

Putting the rule into production

You will need to install Falco to be able to use the rule - the quickest way is to follow the guide at https://falco.org/docs/getting-started/falco-linux-quickstart/. In a nutshell, if you have a modern system you should be able to use eBPF and Falco to deploy the rule and detect exploitation with very high confidence.

After you have installed Falco, just copy and paste the rule into /etc/falco/falco_rules.local.yaml and Falco should automatically pick up the rule.

Why does the rule fire 40x for a single exploit?

When the rule detects activity, it will fire 40 times. Here’s why:

If we break down the Python exploit code you provided earlier, the reason becomes clear.

The Loop Look at the very end of the script:

while i<len(e):c(f,i,e[i:i+4]);i+=4
And look at the start of the c function:

def c(f,t,c):
 a=s.socket(38,5,0); ...

The script is decompressing a binary payload (e) and then using a while loop to write it into memory. However, it writes the payload in 4-byte chunks (e[i:i+4]). For every single 4-byte chunk, it calls the c() function, which creates a brand new AF_ALG socket (s.socket(38,5,0)).

Why does the exploit do this? As we discussed earlier, the core mechanism of this vulnerability involves the kernel doing a temporary “scratch write” of a sequence number during the crypto operation. That scratch write is strictly limited to 4 bytes.

To inject a payload large enough to spawn a root shell (which is typically around 160 bytes of assembly), the attacker cannot just write it all at once. They have to trigger the vulnerability, write 4 bytes, trigger the vulnerability again, write the next 4 bytes, and so on, inching their way through the file cache.

Since a payload of ~160 bytes divided by 4 bytes equals roughly 40 iterations, the script creates ~40 sockets.

Proof is in the detection

If you’re unfortunate enough to be the victim of the copyfail exploit, you will see thw following in the Falco journalctl logs (sudo journalctl _COMM=falco):

Apr 30 07:37:07 ubuntu24 falco[6119]: 07:37:07.944032706: Warning Anomalous AF_ALG socket created (user=hilt uid=1000 command=python3 pid=8280 contai>
Apr 30 07:37:07 ubuntu24 falco[6119]: 07:37:07.944575128: Warning Anomalous AF_ALG socket created (user=hilt uid=1000 command=python3 pid=8280 contai>
Apr 30 07:37:07 ubuntu24 falco[6119]: 07:37:07.945062923: Warning Anomalous AF_ALG socket created (user=hilt uid=1000 command=python3 pid=8280 contai>
Apr 30 07:37:07 ubuntu24 falco[6119]: 07:37:07.945493102: Warning Anomalous AF_ALG socket created (user=hilt uid=1000 command=python3 pid=8280 contai>

Happy hunting! Gemini did most of the grunt work - this is the reality of cybersecurity in 2026, attackers may be faster, but as defenders we can be just as quick if we also bring LLMs to the fight!