Containers fail in predictable ways: an exposed management API, a secret baked into an image, or a privileged pod that hands an attacker the node. This list ranks the ten container risks that appear most often in the NHI Mgmt Group breach database, weighted by how much damage each did. It covers images, registries, runtimes and hosts, whether the containers run on Docker hosts, Kubernetes or managed container services. Cluster-level Kubernetes issues are covered in more depth in our Top 10 Kubernetes Security Risks; this page stays with the container lifecycle. It is written for platform, DevOps and cloud security engineers.
The Top 10 at a glance
The ranking puts first the risks behind real compromises in our database, then those that turn a foothold into a full cloud breach. Each item gives the issue, why it matters and what to do, with the matching NIST SP 800-190 risk and MITRE ATT&CK technique.
| # | Risk | Typical outcome | ATT&CK |
|---|---|---|---|
| 1 | Exposed container APIs and consoles | Remote code execution, cryptomining | T1190, T1610 |
| 2 | Secrets baked into images | Cloud, CI and registry keys leaked to anyone who pulls | T1552.001 |
| 3 | Privileged containers and host mounts | Escape to the node | T1611 |
| 4 | Container to cloud lateral movement | Cloud account takeover from one pod | T1552.007, T1078.004 |
| 5 | Untrusted and poisoned images | Malware running with your workload's identity | T1204.003, T1525 |
| 6 | Over-permissive workload identities | Cluster-wide access from one token | T1609, T1613 |
| 7 | Vulnerable and stale images | Exploitable services in production | T1190 |
| 8 | No admission policy | Risky configurations reach production unchecked | T1610 |
| 9 | Flat networks and open egress | Lateral movement and exfiltration | T1613 |
| 10 | No runtime detection or logging | Compromise found by the cloud bill | T1496.001 |
1. Exposed container APIs and consoles
The issue: the Docker Engine API, the kubelet API or a Kubernetes dashboard reachable from the internet without authentication. Docker listens on a local UNIX socket by default; the problem starts when someone exposes it over TCP (conventionally port 2375 unencrypted, 2376 with TLS) without tlsverify.
Why it matters: an open API means anyone can start a container of their choosing on your host. The Tesla Kubernetes cryptojacking incident began with an open console, the TeamTNT worm spread across exposed Docker hosts, and the Carbonato botnet used the same entry point in 2026 to hunt AI API keys.
What to do: never bind the daemon to a public interface; use SSH or mutual TLS for remote access; disable anonymous kubelet access; scan your external ranges for 2375, 2376, 10250 and dashboard ports every week.
2. Secrets baked into images
The issue: API keys, cloud credentials and .env files copied into image layers, often in a layer later "deleted" by another instruction (the earlier layer still holds it).
Why it matters: every pull is a copy of the secret. Researchers found secrets in 10,456 public Docker Hub images and in the RWTH Aachen study of 337,171 images, and a PyPI admin GitHub token sat in a public image for 15 months.
What to do: use BuildKit secret mounts or multi-stage builds, inject secrets at runtime from a secrets manager, scan images for secrets in CI and in the registry, and rotate anything found. See the Secrets Management Guide.
3. Privileged containers and host mounts
The issue: containers run as root with --privileged (or privileged: true), added capabilities such as SYS_ADMIN, hostPID or hostNetwork, or a hostPath mount of / or /var/run/docker.sock.
Why it matters: containers share the host kernel (NIST SP 800-190 section 3.5.2). With these settings, breaking out to the node is a configuration feature rather than an exploit, and from the node an attacker reaches every other container on it.
What to do: run as non-root, set allowPrivilegeEscalation: false, drop all capabilities, use the RuntimeDefault seccomp profile and a read-only root filesystem. In Kubernetes these settings are what the Pod Security Standards Restricted profile requires. Consider rootless Docker or user namespaces for build hosts.
4. Container to cloud lateral movement
The issue: a pod can reach the cloud instance metadata service and pick up the node's role, or mounts cloud credential files and long-lived access keys.
Why it matters: one compromised container becomes a cloud account compromise. Tesla's exposed environment held AWS credentials, and TeamTNT specifically stole AWS credential files. OWASP lists this as K08 Cluster To Cloud Lateral Movement.
What to do: block metadata access from pods (IMDSv2 with a hop limit of 1 on AWS, or network policy), give each workload its own federated cloud identity (EKS Pod Identity or IRSA, GKE Workload Identity, Azure Workload Identity) and keep node roles minimal. See the Kubernetes NHI Security Guide.
5. Untrusted and poisoned images
The issue: pulling :latest tags from public registries, or trusting an official-looking image without verifying who built it.
Why it matters: attackers publish typosquatted images and compromise real ones. In the Checkmarx KICS attack, stolen credentials were used to poison published Docker images of a security tool.
What to do: pull through an internal registry, pin images by digest, require signatures (for example Sigstore cosign) and SBOMs, and verify them at admission. See the Container Image Security Guide and the Container Registry Security Guide.
6. Over-permissive workload identities
The issue: every pod gets an automatically mounted service account token, and that account is bound to broad roles, sometimes cluster-admin, or can list Secrets (which returns their contents).
Why it matters: the token is a non-human identity that an attacker inherits the moment they land in the container, letting them run exec into other pods and enumerate the cluster.
What to do: set automountServiceAccountToken: false unless the workload calls the API, use one service account per workload, scope roles to named resources, and review bindings quarterly. See the Kubernetes Service Account Token Guide and the Kubernetes RBAC Guide.
7. Vulnerable and stale images
The issue: large base images full of packages nobody uses, rebuilt rarely, and old images left running or sitting in registries (NIST SP 800-190 sections 3.1.1 and 3.2.2).
Why it matters: exposed AI and data services in containers are routinely exploited; the ShadowRay campaign turned exposed Ray clusters into a source of cloud credentials and compute.
What to do: use minimal or distroless base images, rebuild on a schedule rather than patching running containers, scan in CI and continuously in the registry, prioritise vulnerabilities listed in the CISA KEV catalogue, and expire unused images.
8. No admission policy
The issue: nothing stops a privileged pod, an unsigned image or a hostPath mount from being deployed (OWASP K04).
Why it matters: good build-time scanning is wasted if anything can still be deployed with kubectl apply.
What to do: label namespaces with Pod Security Admission (pod-security.kubernetes.io/enforce: restricted, starting in warn and audit mode), and add a policy engine such as Kyverno, OPA Gatekeeper or ValidatingAdmissionPolicy for image provenance and registry allowlists. See the Kubernetes Admission Control Guide.
9. Flat networks and open egress
The issue: by default every pod can reach every other pod and the internet (NIST SP 800-190 sections 3.3.3 and 3.4.2).
Why it matters: a compromised front-end container can reach databases, the metadata service and attacker infrastructure for downloading miners or sending data out.
What to do: default-deny NetworkPolicy per namespace, explicit allow rules, egress through a proxy with an allowlist, and separate nodes or clusters for workloads of different sensitivity.
10. No runtime detection or logging
The issue: no audit logging on the orchestrator, no runtime sensor and container logs that vanish with the container (OWASP K10).
Why it matters: cryptomining (ATT&CK T1496.001 Compute Hijacking) is often noticed through cost alerts rather than security tools, weeks after entry.
What to do: enable Kubernetes audit logs, ship container and node logs off-host, deploy an eBPF-based runtime sensor (Falco or similar) with alerts for shells in containers, new binaries, mining pool traffic and metadata access, and set cloud budget alerts. See the Container Runtime Security Guide.
Mapping to OWASP
The table maps each risk to the OWASP Kubernetes Top 10 (2025 edition), NIST SP 800-190 section 3 and the CIS Docker and Kubernetes Benchmarks area to check. See the NIST SP 800-190 Container Security Guide for the full standard.
| Risk | OWASP Kubernetes Top 10 (2025) | NIST SP 800-190 | CIS Benchmark area |
|---|---|---|---|
| 1. Exposed APIs and consoles | K06, K09 | 3.3.2 Unauthorized access | Docker daemon configuration; kubelet |
| 2. Secrets in images | K03 | 3.1.4 Embedded clear text secrets | Container images and build file |
| 3. Privileged containers | K01 | 3.4.3 Insecure runtime configurations; 3.5.2 Shared kernel | Container runtime; pod security |
| 4. Container to cloud | K08 | No direct equivalent (relates to 3.3.5 Orchestrator node trust) | Managed service benchmarks (EKS, GKE, AKS) |
| 5. Untrusted images | K04 | 3.1.3 Embedded malware; 3.1.5 Untrusted images | Container images and build file |
| 6. Over-permissive identities | K02 | 3.3.1 Unbounded administrative access | RBAC and service accounts |
| 7. Vulnerable images | K07 | 3.1.1 Image vulnerabilities; 3.2.2 Stale images | Container images and build file |
| 8. No admission policy | K04 | 3.4.5 Rogue containers | Pod security policies |
| 9. Flat networks | K05 | 3.3.3 Inter-container traffic; 3.4.2 Unbounded network access | Network policies and CNI |
| 10. No detection | K10 | 3.4.5 Rogue containers | Logging and audit |
Primary sources: NIST: SP 800-190 Application Container Security Guide, OWASP: Kubernetes Top 10, CIS: Docker Benchmark, Kubernetes: Pod Security Standards, Docker: Protect the Docker daemon socket, CISA and NSA: Kubernetes Hardening Guide and MITRE ATT&CK: Escape to Host.
Where to start
If you can do only three things this quarter, close the doors attackers actually use:
- Find exposed APIs (risk 1): scan your public ranges for Docker, kubelet and dashboard ports and close them this week.
- Get secrets out of images (risk 2): run a secrets scan across your registry, rotate every live credential found, then add the scan to CI as a blocking check.
- Cut the path to the node and the cloud (risks 3 and 4): put namespaces into Pod Security Admission
warnmode at Restricted, fix the violations, switch toenforce, and block metadata access from pods.
Track progress with four measures: the number of internet-exposed container endpoints (target zero), the percentage of running images pinned by digest and signed, the percentage of namespaces enforcing Restricted, and the count of workloads using static cloud keys rather than federated identity. Small teams on a managed service should lean on the provider's defaults and a single policy engine; large estates need registry-wide scanning and a runtime sensor on every node. For buying decisions, see the Container Security Buyer's Guide.
Related NHI Mgmt Group resources: Container Security Guide · Kubernetes Security Guide · Top 10 Cloud Security Risks · Top 10 Secrets Management Mistakes