Attackers are actively exploiting misconfigurations in Docker and Kubernetes environments to break out of containers and take full control of 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, according to a new report by researchers at Securelist shared with Cyber Security News.
Why Container Misconfigurations Are So Dangerous
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.
Misconfigurations are far more common as the root cause of successful breaches than complex kernel vulnerabilities. Attackers look for low-hanging fruit first, and insecure container configurations remain plentiful across enterprise environments. Once inside a compromised container, attackers routinely find API keys, SSH keys, access tokens, service credentials, and Kubernetes ServiceAccount tokens — enough to pivot into cloud infrastructure or establish long-term persistence.
Privileged Containers: The Most Dangerous Misconfiguration
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 container escapes when improperly assigned:
- CAP_SYS_ADMIN — allows mounting file systems and interacting with kernel parameters; combined with
hostPathaccess, an attacker can 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 — dangerous when the host PID namespace is shared; allows code injection into host processes and extraction of sensitive data from memory.
- CAP_NET_ADMIN — enables network stack manipulation; with
hostNetwork: true, opens the door to traffic interception across the environment.
Orchestration API Abuse
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.
In one notable case documented by researchers, the APT group TeamPCP compromised the Checkmarx KICS static analysis tool across multiple attack chains, poisoning a Docker Hub repository to steal Kubernetes secrets. This underscores that these attacks have evolved into multi-stage scenarios involving supply chain compromises, Kubernetes secrets theft, and orchestration API abuse.
Supply Chain Attacks Against Container Infrastructure
Beyond runtime misconfigurations, attackers are targeting 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 verifying 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.
Hardening Your Container Environments
To defend against these escalating threats, security teams should take the following steps:
- Audit container configurations regularly and never run containers with the privileged flag unless absolutely necessary.
- Apply the principle of least privilege to Linux capabilities — drop all capabilities not required by the application.
- Verify all container images before use, scanning for known vulnerabilities and checking image provenance.
- Tighten Kubernetes RBAC policies, ensuring tokens cannot be used to create privileged pods.
- Treat CI/CD pipelines as critical infrastructure with strict access controls, secrets rotation, and pipeline integrity verification.
- Deploy runtime monitoring to detect anomalous container behavior, including unexpected outbound connections or privilege escalation attempts.
- Implement supply chain validation including signed images (e.g., with Sigstore/Cosign) and software bill of materials (SBOM) generation.
As containerized environments become the backbone of enterprise infrastructure, securing them against both misconfiguration abuse and supply chain attacks is no longer optional — it is a foundational security requirement.