Docker and Kubernetes Misconfigurations Are Being Abused to Compromise Host Systems

Attackers are increasingly abusing Docker and Kubernetes misconfigurations to move from containers into host systems, cloud infrastructure, and orchestration control planes. The threat is not limited to rare zero-day exploits. In many cases, attackers use exposed APIs, weak permissions, privileged containers, stolen secrets, and poisoned images to expand access.

A recent Securelist report says container attacks have evolved into multi-stage operations involving supply chain compromise, Kubernetes secrets theft, orchestration API abuse, and container escape attempts. The report also notes that misconfigurations remain one of the most common causes of successful container escapes.

This matters because containers share the host operating system kernel. A container may look isolated, but unsafe runtime settings can give attackers a path to host devices, host namespaces, service account tokens, secrets, and management APIs.

Why container misconfigurations are a serious host risk

Containers protect applications through layers such as namespaces, cgroups, Linux capabilities, seccomp, AppArmor, and SELinux. These controls help separate container workloads from the host. But administrators can weaken that separation with a single risky setting.

The most dangerous example is a privileged container. The Docker documentation says the privileged flag gives all capabilities to a container, enables access to host devices, and reconfigures AppArmor or SELinux so the container has nearly the same access as processes running outside the container.

In Kubernetes, risky pod settings can create similar exposure. The Kubernetes Pod Security Standards say sharing host namespaces should be disallowed and list hostNetwork, hostPID, and hostIPC as restricted fields under tighter security policies.

Key risks at a glance

Risk area	Common misconfiguration	Possible impact
Runtime privileges	Privileged containers or excessive Linux capabilities	Container escape and host compromise
Host access	hostPID, hostNetwork, hostIPC, or broad hostPath mounts	Process abuse, network interception, or host file access
Secrets	Overexposed Kubernetes Secrets or service account tokens	Cloud account access and lateral movement
Orchestration APIs	Exposed Docker API or weak Kubernetes RBAC	Remote workload deployment and cluster takeover
Supply chain	Unverified images, mutable tags, and compromised CI/CD flows	Malicious code entering production builds

Attackers do not always need to escape the container immediately. A compromised container can already contain valuable material, including API keys, cloud credentials, SSH keys, database credentials, and Kubernetes tokens.

The Kubernetes Secrets documentation warns that Secrets are stored unencrypted by default in the API server’s underlying data store, etcd. It also says anyone with API access can retrieve or modify a Secret, and anyone allowed to create a Pod in a namespace may gain indirect access to Secrets in that namespace.

Privileged containers remain one of the fastest paths to host compromise

A privileged container can collapse much of the normal boundary between the workload and the host. If an attacker gains code execution inside that container, the next step may involve mounting host filesystems, accessing devices, or using namespace tooling to reach host processes.

Specific Linux capabilities also create risk when teams add them without a clear need. CAP_SYS_ADMIN can enable sensitive kernel and filesystem operations. CAP_SYS_MODULE can support kernel module loading. CAP_SYS_PTRACE can allow process memory inspection and manipulation. CAP_NET_ADMIN can enable network configuration changes.

These capabilities become more dangerous when combined with host namespace sharing or broad hostPath mounts. For example, a pod with hostPID can expose host processes to the container, while hostNetwork can place the workload directly on the node’s network stack.

Kubernetes APIs and service accounts can widen the blast radius

Misconfigured orchestration APIs can turn a single foothold into broad control. An exposed Docker API over TCP can give attackers administrative control over containers and, in some cases, the host. A weak Kubernetes service account can allow attackers to list secrets, create pods, or deploy privileged workloads.

The Kubernetes service accounts documentation says RBAC should grant the minimum permissions required by each service account. Pods using that account should not receive more permissions than they need to function.

Least privilege matters because attackers often search for service account tokens after entering a container. If that token has broad permissions, the attacker can query the Kubernetes API, read resources, deploy new workloads, and move laterally inside the cluster.

Supply chain attacks are hitting container infrastructure before deployment

Container risk now starts before runtime. Attackers increasingly target images, registries, CI/CD pipelines, developer tools, and infrastructure-as-code workflows. A malicious image or compromised build step can place attacker-controlled code inside environments that otherwise look legitimate.

Docker recently described a Checkmarx KICS incident in which malicious images were pushed to the checkmarx/kics Docker Hub repository using valid Checkmarx publisher credentials. Docker said the compromised images kept the legitimate scanning surface intact but added a quiet exfiltration path.

Trend Micro’s analysis of TeamPCP described the Checkmarx KICS and elementary-data incidents as part of a broader supply chain campaign. Researchers said the campaign targeted GitHub tokens, npm tokens, cloud credentials, SSH keys, Kubernetes secrets, database credentials, infrastructure files, and crypto wallet keystores.

Common attack paths defenders should watch

• Containers running with the privileged flag.
• Pods that share hostNetwork, hostPID, or hostIPC.
• Containers with broad hostPath mounts into sensitive host directories.
• Unnecessary Linux capabilities such as CAP_SYS_ADMIN, CAP_SYS_MODULE, CAP_SYS_PTRACE, or CAP_NET_ADMIN.
• Docker API endpoints exposed over TCP without strong authentication and network controls.
• Kubernetes service accounts with broad RBAC permissions.
• Secrets mounted into pods that do not need them.
• Images pulled by mutable tags instead of trusted digests.
• CI/CD runners that can access production credentials or cloud secrets.

The Securelist analysis also warns that modern container attacks often aim beyond the container itself. Attackers may seek persistence, host-level access, or control over infrastructure management through Docker and Kubernetes APIs.

That makes runtime detection important. Security teams should monitor for unexpected privileged containers, suspicious pod creations, unusual API calls, new hostPath mounts, outbound connections from CI runners, and command execution in containers that should not run shells or package managers.

How to reduce Docker and Kubernetes exposure

Control	Recommended action	Why it helps
Runtime privileges	Block privileged containers unless there is a documented exception	Reduces host access from compromised workloads
Linux capabilities	Drop all capabilities by default and add only what the workload needs	Limits escape and kernel interaction paths
Host namespaces	Disable hostPID, hostNetwork, and hostIPC for normal workloads	Preserves isolation between pods and nodes
RBAC	Grant service accounts only the permissions they need	Limits API abuse after token theft
Secrets	Encrypt Secrets at rest and restrict access to specific workloads	Reduces damage from exposed tokens and credentials
Images	Pin images by digest and scan them before deployment	Prevents silent tag overwrite and reduces supply chain risk
CI/CD	Limit secrets available to pipelines and rotate credentials after suspected exposure	Reduces the impact of poisoned builds and compromised runners

Docker’s own guidance for running containers supports this approach. The Docker run documentation explains that containers are unprivileged by default and that privileged mode gives expanded access to host devices and security controls.

For Kubernetes, the Pod Security Standards provide a clear baseline for restricting risky pod behavior. Teams should enforce those controls through admission policies, policy engines, or managed Kubernetes security features.

Secrets and RBAC need special attention

Secrets management remains a major weak point because attackers often find credentials faster than they find an escape exploit. Once they obtain a token with broad permissions, they may no longer need to break out of the container in a traditional sense.

The Kubernetes Secrets guide recommends enabling encryption at rest, configuring least-privilege RBAC rules for Secrets, restricting Secret access to specific containers, and considering external secret store providers.

Likewise, Kubernetes service account guidance points administrators toward least privilege. Teams should review every default service account, remove unused tokens, and avoid giving workloads cluster-wide permissions unless the workload truly requires them.

The Checkmarx KICS incident shows why image trust matters

The KICS incident shows how attackers can target the tools organizations use to secure infrastructure. If a scanner image gets poisoned, its output may expose cloud resources, internal topology, and secrets from the repositories it scans.

Docker said users who ran affected KICS images against repositories with credentials in scope should rotate those credentials, re-pull by digest, purge cached malicious digests, and check logs for outbound traffic to attacker-controlled infrastructure. That advice applies broadly to compromised container images.

The broader TeamPCP campaign shows why CI/CD security belongs in any container defense plan. Build pipelines often have the exact credentials attackers want, including registry tokens, cloud keys, package publishing tokens, and deployment secrets.

What enterprises should do now

• Audit Kubernetes manifests, Helm charts, and Docker Compose files for privileged settings and host namespace sharing.
• Search for containers with CAP_SYS_ADMIN, CAP_SYS_MODULE, CAP_SYS_PTRACE, or CAP_NET_ADMIN.
• Block unauthenticated access to Docker and Kubernetes management APIs.
• Review service account RBAC and remove broad cluster-wide roles from normal workloads.
• Encrypt Kubernetes Secrets at rest and restrict which pods can access them.
• Pin production images by digest and use trusted registries.
• Scan images and CI/CD artifacts for malware, secrets, and unexpected build changes.
• Monitor runtime behavior for shell access, new mounts, suspicious egress, and unexpected pod creation.
• Rotate credentials after any suspected image poisoning or pipeline compromise.

Container security now requires controls across the whole lifecycle. Teams need safe images, hardened builds, restricted runtime settings, tight API access, monitored service accounts, and clear incident response playbooks.

The central lesson is simple. Containers do not remove host risk by default. Docker and Kubernetes can provide strong isolation, but attackers can abuse weak configuration choices to turn a compromised workload into a host, cluster, or supply chain breach.

FAQ