What happens when a malicious container image is used with kubectl cp on a vulnerable client?

A malicious image can supply a crafted tar archive that abuses kubectl’s unpacking behavior on the client machine. If the archive includes relative paths or symlink tricks, files may be written outside the intended directory. That can overwrite local files, create persistence, or enable code execution, especially when the client has broad privileges.

How kubectl cp becomes dangerous on a vulnerable client

kubectl cp is convenient because it streams an archive from the container and extracts it on the local machine. The problem is that the client must trust the archive contents during unpacking. If the archive is crafted to manipulate paths or symlinks, the extraction step can write outside the target directory and affect files the user never intended to touch.

That shifts the risk from a simple file copy into a local file-write primitive. On a workstation with broad filesystem access, the result can be configuration tampering, credential exposure, persistence, or execution of attacker-controlled code through a modified startup file or script.

How the exploit works in practice

The malicious container image does not need to break Kubernetes itself. It only needs to control what the client receives when kubectl cp asks for files. A vulnerable client may unpack a tar archive without sufficiently constraining path traversal, symbolic links, or other archive tricks. If extraction logic accepts a path like ../ or follows a symlink into another location, the write can land outside the intended destination.

That makes the attack especially effective when the operator runs kubectl from a privileged account, a developer laptop with access to source code or cloud credentials, or a jump host with sensitive local state. The container is merely the delivery vehicle, while the client-side unpacking bug is the real failure point.

For container-focused guidance on image, registry, and runtime exposure, see NIST SP 800-190 Container Security. For a broader view of how malicious or over-permissive container content can expose secrets, Docker Hub Auth Secrets in Container Images is a useful companion reference, and Massive Docker Hub Secrets Leak shows how often container images carry unintended sensitive material.

What the attacker gains from a successful write outside the target directory

Once the attacker can place or overwrite files on the client, the impact depends on what the user account can access. Replacing shell profiles, editor startup files, scheduled tasks, or application configuration can create persistence. Dropping a script into a directory that is later executed can lead to code execution. Overwriting dotfiles or SSH-related material can also expose follow-on access if those files are later used by tools or automation.

The key point is that the compromise is local first, but it can quickly become broader if the client workstation is trusted for cloud access, source control, or administrative operations. In that sense, a kubectl cp bug is not just a file integrity issue, it is a workstation trust boundary failure.

Where defenders should focus first

The safest assumption is that archive extraction on the client is untrusted input handling, not a harmless copy operation. Treat any kubectl cp workflow as security-sensitive when it crosses from an untrusted container into a privileged workstation. The practical question is not whether the image is “malicious” in an abstract sense, but whether the client can be induced to unpack attacker-controlled paths.

For standards-based hardening, review NIST SP 800-53 Rev 5 Security and Privacy Controls for file integrity, least privilege, and configuration management controls, and use CSA Cloud Controls Matrix to map cloud and workload governance expectations around IAM, logging, and secure operations. If the issue is being handled as part of a broader vulnerability remediation program, the CISA Known Exploited Vulnerabilities Catalog is the right place to track exploitability and urgency.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	SI-7 — Software, Firmware, and Information Integrity	Archive path abuse can alter local files and integrity.
	AC-6 — Least Privilege	Impact expands when the client runs with broad filesystem rights.
	CM-7 — Least Functionality	Reducing tools and writable paths limits blast radius from client-side extraction flaws.
Recommendation — Validate extracted files and block unsafe archive writes. Run copy workflows with the minimum filesystem and account privileges. Restrict unnecessary client tooling and writable locations.
ISO/IEC 27001:2022	A.8.9 — Configuration management	Unsafe client extraction is a configuration and integrity control issue.
Recommendation — Harden client-side copy and extraction settings to prevent path abuse.
CIS Controls v8	CIS-4 — Secure Configuration of Enterprise Assets and Software	Vulnerable client behavior is mitigated by secure workstation configuration.
Recommendation — Enforce hardened client configurations for kubectl and archive handling.

Practitioner Guidance

What to verify: Confirm whether the client version uses a tar extraction path that resists traversal and symlink abuse. If you cannot prove that behavior is safe, assume kubectl cp can be used to write outside the destination tree.

Decision rule: If the source container is not fully trusted, prefer safer transfer methods or isolate the copy operation in a disposable environment. If the workstation has access to sensitive credentials, treat any unexpected file write as a potential compromise event, not a minor copy glitch.

Common mistake: Assuming “I only copied files out of a container” makes the operation low risk. The dangerous step happens on the client during extraction, so the risk is local privilege, persistence, and integrity loss on the operator machine.

Practitioner takeaway: The security boundary is the client filesystem, not the container image. If the archive is attacker-controlled, kubectl cp should be treated like untrusted archive extraction with the potential for local takeover.