Kubernetes CVE-2026-19444: Update Windows kubectl Before Copying From Untrusted Pods


Kubernetes has disclosed CVE-2026-19444, a Windows-only path-traversal flaw in kubectl cp that can let a malicious container write files to arbitrary locations on the administrator's local machine. The Kubernetes Security Response Committee rates the issue Medium, CVSS 6.5, and published fixes on September 28, 2026.

The vulnerable operation is copying files from a container to a Windows machine with kubectl cp. If the container is untrusted and supplies a malicious tar implementation, crafted archive output can escape the destination selected by the user. Writes remain limited by the permissions of the Windows account running kubectl.

Administrators using Windows clients should update to kubectl 1.34.12 or later, 1.35.9 or later, or 1.36.5 or later within those release branches. Kubernetes' current Windows installation documentation also lists the newer 1.37 release line; normal kubectl compatibility guidance is to keep the client within one minor version of the cluster control plane.

Affected and fixed kubectl versions

Release line Affected Windows clients Fixed version
1.34 1.34.0–1.34.11 1.34.12+
1.35 1.35.0–1.35.8 1.35.9+
1.36 1.36.0–1.36.4 1.36.5+

The Kubernetes advisory says Linux and macOS kubectl clients are unaffected. The vulnerable component is the local Windows kubectl client, so this advisory is primarily an administrator-workstation and CI-runner update rather than a Kubernetes control-plane patch requirement.

Check the installed client with:

kubectl version --client

Organizations that distribute kubectl.exe through endpoint-management tools, developer images or Windows CI runners should inventory those copies as well as interactive administrator workstations.

How the file write happens

kubectl cp relies on tar inside the container to construct the archive sent back to the client. CVE-2026-19444 becomes relevant when the container contents or its tar executable cannot be trusted. A malicious implementation can emit archive paths that cause the Windows extraction path to reach locations outside the requested destination.

The impact is an arbitrary local file write within the privileges of the user running kubectl. That makes privileged administrative workstations particularly important to update because the resulting write capability follows the operator's local Windows permissions.

The issue is tracked in Kubernetes issue #141294 and appears in the project's official CVE feed. Kubernetes credits Moriel Harush with reporting the vulnerability and Marly Salazar, Maciej Szulik and Vyom Yadav with coordinating the fix.

What to do before upgrading

Kubernetes' mitigation is concise: copy files only from containers you trust, or avoid kubectl cp from untrusted containers on Windows until the client is updated.

For operational environments, the practical sequence is:

  1. Run kubectl version --client on Windows administrator systems and CI runners.
  2. Compare the result with the affected ranges above.
  3. Upgrade to the fixed patch release for the release line in use, while keeping the normal one-minor-version client/control-plane compatibility rule in mind.
  4. Until the update is deployed, avoid copying files from containers whose contents are controlled by tenants, build jobs or other untrusted workloads.

The Kubernetes advisory asks users who find evidence of exploitation to contact the project's security team. It does not report observed exploitation in the advisory itself.

Deployment impact

CVE-2026-19444 has a narrower exposure condition than a remotely exploitable cluster vulnerability: an affected Windows client must invoke kubectl cp against container content it does not fully trust. That condition is realistic in incident response, multi-tenant operations and build environments, where administrators often retrieve logs or artifacts from workloads they are investigating.

Updating the client closes that local extraction path while preserving the existing kubectl cp workflow. Teams with centrally managed Windows engineering machines can address the issue through their normal kubectl package or binary-distribution process without changing Kubernetes server configuration solely for this CVE.

Sources