The Expanding Attack Surface: Navigating Container Escape and Supply Chain Risks in Docker and Kubernetes

As containerization transitions from a modern convenience to the structural backbone of cloud-native infrastructure, the threat landscape is undergoing a fundamental shift. Adversaries are moving away from traditional endpoint exploitation and are increasingly focusing on the intricacies of container ecosystems. In these environments, a single misconfiguration or a minor breakdown in isolation boundaries can escalate from a localized breach to a full-scale cluster compromise.

A chilling example of this evolution is seen in recent campaigns attributed to the APT group TeamPCP. Rather than attempting a brute-force entry, they utilized a sophisticated supply chain attack by poisoning a Docker Hub repository utilized by Checkmarx KICS. By embedding a credential stealer that activated during routine security scans, the attackers demonstrated how even trusted security tooling can be weaponized to harvest Kubernetes secrets and sensitive credentials.

The Fragility of Isolation: Kernel Exploitation and Container Escapes

Technically, containers are not virtual machines; they are isolated processes that rely on a shared host kernel. They utilize Linux primitives—specifically namespaces for resource visibility and cgroups (control groups) for resource limitation—to create the illusion of separation. This shared architecture is a double-edged sword. If an attacker compromises a containerized process, their primary objective is to “escape” that boundary to interact directly with the host kernel.

History has shown that even robust runtimes are susceptible to memory corruption and logic flaws. For instance, the infamous CVE-2019-5736 allowed attackers to overwrite the runC binary, granting them host-level code execution. More recently, research from Securelist highlighted how CVE-2022-0492 enabled escapes via improper cgroup handling, and how CVE-2024-21626 exploited flaws in file descriptor management to expose the host file system.

Beyond zero-day vulnerabilities, attackers frequently leverage “living-off-the-land” techniques by abusing excessive Linux capabilities. Running a container in --privileged mode or granting dangerous capabilities like CAP_SYS_ADMIN effectively dismantles the security perimeter, allowing an attacker to mount the host’s root file system directly into the container to achieve persistence.

Exploiting Orchestration: API Misconfigurations and Privileged Access

In a Kubernetes environment, the control plane is the ultimate prize. Misconfigured APIs—specifically those exposed without robust authentication or fine-grained Role-Based Access Control (RBAC)—provide a frictionless entry point. An attacker who obtains a Kubernetes API token can enumerate the cluster’s topology and deploy malicious, highly privileged pods designed specifically for lateral movement or escape.

One particularly dangerous capability is CAP_SYS_PTRACE. This allows a process to observe and manipulate the memory of other processes. In a shared environment, this can be used to inject malicious code into sensitive processes or extract plain-text credentials directly from memory.

Similarly, mounting the /var/run/docker.sock inside a container is a critical security failure. Because the Docker socket allows communication with the Docker daemon, anyone with access to it effectively possesses root privileges over the entire host, enabling them to launch new containers that bypass all existing security constraints.

The Multi-Stage Attack Chain: From Pipeline to Cluster

Modern container attacks are rarely single-event incidents; they are orchestrated, multi-stage operations. The chain typically follows this progression:

• Initial Access: Often via supply chain poisoning (malicious base images) or CI/CD pipeline injection.
• Credential Harvesting: Scavenging environment variables, mounted secrets, or API tokens within the compromised container.
• Lateral Movement: Using harvested identities to move from a single pod to the wider Kubernetes namespace or the cloud provider’s metadata service.
• Escalation/Exfiltration: Achieving host escape or total cluster takeover to exfiltrate data or deploy ransomware.

It is vital to recognize that an attacker may not even need to “escape” to be successful. If a container has access to a cloud service account with overly broad permissions, the attacker can pivot from the container to the entire cloud infrastructure, impersonating services and compromising the data plane without ever touching the host kernel.

To defend these complex environments, organizations must move toward a “Zero Trust” container model. This requires implementing strict Pod Security Admissions, utilizing minimal base images (like Distroless), enforcing the principle of least privilege for all Linux capabilities, and maintaining continuous, real-time monitoring of both container runtimes and API audit logs.