Tracking Copy Fail exploitation in production environments

Tracking Copy Fail exploitation in production environments

Background

The Copy Fail vulnerability (CVE-2026-31431) is a Linux kernel bug in the AF_ALG cryptographic socket interface, present in default kernel configurations across many of the Linux distributions that hyperscalers run. The bug allows a local user - including one inside an unprivileged container - to gain root on the host. No special capabilities are required, which means any process that can open a socket and call splice() is a potential exploit vector.

In a Kubernetes environment, the route to that local user is short. An adversary who compromises an identity carrying pods/exec permissions can use kubectl exec to land a shell inside any pod in the cluster, run the Copy Fail exploit against the pod's kernel (which is the node's kernel), and break out to root on the underlying node. Attribution of that activity is the hard part. The exploit runs inside the pod's process namespace. The originating identity sits several layers removed in the cloud control plane. Drawing the line from kernel-level activity on the node back to the human, non-human, or third party that issued the kubectl exec is a problem most security tooling does not solve.

For example, at the kernel level, the kubectl exec appears as a local process. The originating IAM role, the SSO session, and the human behind both are not visible on the node. A runtime sensor that only instruments the node sees the exploit run but cannot name the originating identity. A cloud identity tool that only watches the control plane sees the exec permission fire but cannot see what executed on the node. The attribution gap sits between those two layers. ClearVector instruments the node and watches the control plane simultaneously, connecting node-level activity to the identity that authorized the exec.

The rest of this post walks through a demonstration in our research cluster.

Detecting Copy Fail

Assume an adversary (or insider) has compromised an identity in the research cluster and selects the pod named mypython as the target. The adversary issues the command shown in Figure 1, which writes a Python exploit into the pod and runs that exploit against the kernel.

kubectl exec mypython -- bash -c "echo 'import os as g,zlib,socket as s' > exploit.py;echo 'def d(x):return bytes.fromhex(x)' >> exploit.py;echo 'def c(f,t,c):' >> exploit.py…/SNIP/... >> exploit.py;echo 'g.system(\"su\")' >> exploit.py;python exploit.py"

Figure 1. kubectl exec Copy Fail proof of concept

The command travels through the cluster along the path shown in Figure 2: the cloud control plane authenticates the originating identity, the API server forwards the exec to the kubelet on the target node, and the kubelet spawns the bash process inside the mypython pod. The ClearVector sensor instruments every node in the cluster and sees the bash process, the Python interpreter, and every process and syscall the exploit produces.

Figure 2. kubectl exec command flow

On the node, the kubectl exec command spawns the chain of processes shown in Figure 3. The bash shell writes exploit.py through a series of echo redirections, then invokes python to run the exploit. The python process carries out the Copy Fail exploitation and finally launches su, which on a successfully exploited host returns a root shell. The ClearVector sensor on the node sees every step of that process tree, from the initial bash inside the pod through the privileged su on the host.

Figure 3. Process tree on the node

Because ClearVector sees activity on the node alongside the cluster's control plane identity activity, ClearVector tracks adversary activity on the node back to the identity that issued the kubectl exec using the ClearVector identity graph. The resulting narrative, shown in Figure 4, names the originating identity, the pod where the exploit ran, the node hosting that pod, and the process tree that executed the Copy Fail exploit and all of its child processes.

Figure 4. The ClearVector narrative

Mapping adversary activity on a Kubernetes node back to the identity that issued an exec command can take hours of manual log correlation and in many environments proves impossible. ClearVector makes that attribution trivial.

See the activity

ClearVector maps activity across production back to the human, non-human, or third party that caused that activity - whether the activity is an ordinary API call or a kernel exploit chained through kubectl exec. To see this in your own environment, request a demo at [email protected].

‍