Attackers are actively exploiting misconfigurations in Docker and Kubernetes environments to break out of containers and take full control of the underlying host systems.
What was once a niche concern has grown into a serious and escalating threat, with attackers running multi-stage operations that extend well beyond a single compromised container.
Modern container platforms are designed to isolate applications from one another and from the host. But that isolation is only as strong as the configuration behind it.
When settings are applied carelessly or left at insecure defaults, the wall between a container and its host becomes dangerously thin, giving attackers a direct path to escalate privileges.
Researchers at Securelist said in a report shared with Cyber Security News (CSN) that these attacks have evolved into multi-stage scenarios involving supply chain compromises, Kubernetes secrets theft, orchestration API abuse, and container escape attempts.
In one notable case, the APT group TeamPCP compromised Checkmarx KICS across multiple attack chains, poisoning a Docker Hub repository to steal Kubernetes secrets.
The threat is not limited to exotic zero-day exploits. Misconfigurations are far more common as the root cause of successful breaches than complex kernel vulnerabilities. Attackers look for the low-hanging fruit first, and insecure container configurations remain plentiful across enterprise environments.
Once inside a compromised container, an attacker rarely needs to do much to find something valuable. Containers routinely hold API keys, SSH keys, access tokens, service credentials, and Kubernetes ServiceAccount tokens.
These assets alone can be enough to pivot into cloud infrastructure or establish long-term persistence without ever escaping the container.
Attackers Abuse Docker and Kubernetes Misconfigurations
The most dangerous configuration a container operator can enable is the privileged flag. When a container runs with this setting, it receives all Linux capabilities and direct access to host devices, making it functionally equivalent to root access on the host machine.
Using a utility like nsenter, an attacker can spawn a shell outside the container and move freely on the underlying system.
Specific Linux capabilities also open the door to escapes when improperly assigned. The CAP_SYS_ADMIN capability allows a container to mount file systems and interact with kernel parameters.
Combined with access to host directories through the hostPath parameter, an attacker can mount the host disk inside the container and overwrite critical system files. CAP_SYS_MODULE lets an attacker load a malicious kernel module that triggers a reverse shell from kernel space.
CAP_SYS_PTRACE becomes dangerous when the host PID namespace is shared via hostPID: true.
An attacker can then attach to host processes, inject code, and extract sensitive data from memory. CAP_NET_ADMIN enables network stack manipulation and, when combined with hostNetwork: true, opens the door to traffic interception across the environment.
Orchestration APIs present an equally serious risk. An exposed Docker API accessible over TCP without authentication gives an attacker remote administrative access to the host.
A compromised Kubernetes token with weak RBAC policies can allow deployment of privileged pods and a full cluster takeover with just a few API calls.
Supply Chain Attacks Targeting Container Infrastructure
Beyond runtime misconfigurations, attackers are going after containers before they are even deployed. Supply chain attacks target the image build and delivery process, injecting malicious code at stages where organizations are least likely to look.
Developers who pull public images from Docker Hub without checking their origin are especially vulnerable, since threat actors regularly publish tainted images that mimic legitimate tools.
CI/CD pipelines are another high-value target. These systems hold elevated privileges and broad infrastructure access.
By compromising a single pipeline stage, an attacker can modify Docker image builds, quietly adding hidden scripts or remote management tools, while the container appears legitimate on the outside.
To defend against these threats, teams should audit container configurations regularly and avoid running containers with the privileged flag.
All images should be verified before use, RBAC policies should be tightened, and CI/CD pipelines treated as critical infrastructure with strict access controls. Runtime monitoring and supply chain validation are essential parts of any secure container deployment.
