CVE-2026-19444: How copying in kubectl breaks trust

CVE-2026-19444 is a path traversal exploit in the kubectl cp command that lets a malicious container write files anywhere your Windows user account can write. It was assigned a CVSS score of 6.5 by the Kubernetes CNA, so Windows users are strongly recommended to upgrade, and the Kubernetes maintainers have backported these changes to simplify this process in case you are running behind the current release.

The bug lives on the client, not the cluster. Nothing about your control plane or nodes changes the risk. What matters is which laptops and jump boxes run an affected kubectl, and which containers their users copy files out of. The exposure is also fairly broad. ZeroHour estimates somewhere between 100,000 and 1,000,000 Windows kubectl installations exist in the wild - don’t hold us to that number.

How Does The kubectl cp Command Work

The kubectl cp command and the underlying Container Runtime Interface (CRI) that Kubernetes uses to interact with containers has no file-transfer protocol of its own. Copying out of a pod borrows kubectl exec and a tar stream:

1. kubectl asks the API server to execute tar cf - <path> inside the target container.
2. The kubelet execs into the container and runs the tar binary, which is required to be located on the container's own filesystem.
3. The archive streams back over the exec connection to your machine.
4. Finally, kubectl unpacks the stream and writes each entry to your local destination.

Step 2 is where the trust system breaks down. The tar that runs is whatever the container ships, so an attacker who controls the image or the running container controls the archive. The advisory specifically describes how a malicious tar could run any code and emit any output it likes via this vulnerability.

So in this case, it ends up making step 4 the real security boundary. The kubectl tool must treat every entry name in the stream as potentially hostile and therefore must refuse any path that resolves outside the destination directory. CVE-2026-19444 is a case where that check fails on Windows, so a crafted entry lands wherever the attacker points it. This isn’t necessarily a new class of bug for kubectl cp, this was solved in Linux systems but not Windows due to missed translating / to \. The tar-extraction step has drawn several earlier path traversal CVEs, which is a reminder that archive unpacking is hard to get right across multiple OSs.

The History of kubectl cp

Originally kubectl cp had no filtering or any kind of safety mechanisms. As Kubernetes became more broadly deployed, malicious actors quickly found this subcommand as a very broad surface area for attack. The masked use of exec commands, paired with a perhaps surprising requirement of the tar binary, which most operating systems come packaged with preventing from users really knowing they’re using it, is ripe for exploitation. In 2019 there were three CVEs reported for this command (two high and one medium) that exploited the same kind of path traversal exploitation. The fixes were provided for MacOS and Linux systems, but incomplete fixes were provided for Windows which escaped detection until this year.

Why No File Copy API in the CRI?

There has been a KEP (Kubernetes Enhancement Proposal) open for adding this API to the CRI to be consumed by any Kubernetes client, however this is a pretty broad change which requires buy-in from all the CRI providers. It is not a small task, and standardization over such a broad set of potential sources and destinations is very difficult. I, along with other members of SIG CLI and SIG Node, have tried to drum up support for adding this but so far have come up short. I’m hoping that adding this in our containerd-shim can at least demonstrate a path forward, and even drive forward the ability to enable this in other CRIs.

How Serious Is CVE-2026-19444 Really?

Kubernetes is radically different today from its original design. Administrators and users don’t necessarily know the source of the images that they run in their clusters anymore. This vulnerability can be easily chained with supply chain attacks (🥁) injecting malicious versions of the tar binary into them. It is certainly a complicated attack vector, but it is also not one that should be ignored. This vulnerability has been backported to several versions behind latest enabling easier upgrading so I would recommend taking a very low risk upgrade to close the vector off.

Reading the CVE-2026-19444 CVSS Vector

The score is CVSS:3.1/AV:A/AC:L/PR:H/UI:R/S:C/C:L/I:H/A:N, which again, worked out at 6.5. The Medium assigned severity label undersells one thing, and that’s the fact that an arbitrary file write on your dev machine could realistically turn into code execution. This could be achieved by dropping a file into a Startup folder, or by overwriting a script the user runs later. However, we can see why the higher privileges required to achieve this is what’s keeping the score down from HIGH/CRITICAL CVE.

Am I Affected by CVE-2026-19444?

Basically, you’re affected if you run kubectl on Windows and use kubectl cp to copy files from a container whose contents you do not fully control. Check your client version:

kubectl version --client

The advisory lists only these three lines. If you run a kubectl older than 1.34, you are outside Kubernetes' supported window and should upgrade regardless. Linux and macOS clients are not affected by this CVE. The server version does not matter either, since the flaw is in client-side extraction. Finally, upgrading the client is the only fix. Everything else reduces exposure until the fix lands.

The Bigger Lesson: Dev Workstations Are Cluster Attack Surface

In short, if an attacker places a malicious tar binary inside a container and a user runs kubectl cp to copy files from that container, the client is exposed to attacker-controlled behaviour from that binary. The existing safety mechanism, which protects against malicious path traversal in the tar archive, only worked on Linux. This disclosure extends that protection to Windows as well.

Anything a container sends back should be treated as attacker-controlled data, including output from tools that appear to be standard or trusted. The kubectl cp operation was implicitly relying on a tar binary inside the container without independently vetting it, so the client needs to defend itself against malicious behaviour. The broader takeaway is that your dev workstations are part of the cluster's attack surface, and the tooling they use should be patched and maintained with the same care as other production dependencies.