Cloud Container Vulnerabilities

Last Updated on June 6, 2026 by Arnav Sharma

Containers changed everything about how we deploy software. They’re fast, portable, and they scale beautifully. But here’s the thing nobody puts on the conference slide deck: when containers go wrong, they don’t just go a little wrong. They go catastrophically, chain-reaction, “how did they get into our S3 buckets” wrong.

I’ve spent a lot of time working through container security posture assessments, and the pattern repeats itself. An organisation spins up Kubernetes, ships workloads fast, and somewhere along the way, a privileged pod or an exposed metadata service quietly opens a door that leads straight from one container into the host, across the cluster, and deep into cloud infrastructure. Not through some exotic zero-day. Through misconfiguration.

This post breaks down exactly how that happens, why containers create a uniquely dangerous attack surface compared to traditional VMs, and what you can do about it in 2026.

The Container Threat Landscape Right Now

Let’s ground this with some numbers that should make any security architect uncomfortable.

Sysdig’s 2025 Cloud-Native Security Report found that 87% of container images running in production contain a high or critical vulnerability. Red Hat’s 2024 State of Kubernetes Security report showed that 90% of enterprises experienced at least one Kubernetes security incident in the past 12 months. And Vectra AI tracked a 34% increase in container-based lateral movement attacks through 2025.

Perhaps the most alarming stat comes from Google Cloud’s H1 2026 Threat Horizons report: threat actors are exploiting misconfigured containers and deploying secondary payloads in under an hour. New Kubernetes clusters are receiving their first attack attempt within 18 minutes of deployment. Eighteen minutes. That’s less time than most teams spend on their morning standup.

The container and Kubernetes security market is projected to grow from USD 1.7 billion in 2024 to somewhere between USD 8 and 9 billion by the early 2030s. That growth is driven by pure necessity. Organisations face an average of 1,925 cyberattacks per week in cloud environments as of Q1 2025, and the attackers aren’t using sophisticated tooling. IBM X-Force’s 2025 cloud engagement data confirmed that most cloud intrusions didn’t rely on advanced exploitation at all. Attackers simply leveraged weaknesses in identity controls, workload configuration, and hybrid-cloud integration.

Why Containers Are Fundamentally Different from VMs

This is something that trips up teams migrating from VM-based infrastructure. Virtual machines provide hardware-level isolation through hypervisors. Each VM gets its own kernel, its own memory space, its own hardware abstraction. Containers don’t work that way.

Containers share the host kernel. Their isolation depends entirely on a stack of Linux kernel features: namespaces for process separation, cgroups for resource limits, capabilities for privilege boundaries, seccomp profiles for syscall filtering, and mandatory access control through AppArmor or SELinux. Each one of those layers is a potential bypass vector. When any of them gets compromised through a vulnerability or a misconfiguration, the wall between “inside the container” and “running on the host” dissolves.

Think of it this way. A VM is like a separate apartment in a building, with its own foundation, walls, and utilities. A container is more like a cubicle in an open-plan office. The dividers give you the illusion of separation, but you’re still sharing the same floor, the same air conditioning, and the same Wi-Fi. Knock one divider over and suddenly you’re in someone else’s workspace.

The Expanding Attack Surface

Containers introduce a multi-layered security challenge that spans three distinct tiers:

The Image Layer is where vulnerabilities get inherited through reused base images and open-source dependencies. A single weakness can propagate across hundreds of deployments before anyone notices. Container supply-chain vulnerabilities grew 28% in 2025, largely because of unverified open-source dependencies that teams pull without a second thought.

The Orchestration Layer is Kubernetes itself, and this is where misconfigurations around RBAC, service accounts, and API exposure create cluster-wide blast radius. Over 50% of respondents in Red Hat’s 2024 report cited misconfigurations as the leading cause of Kubernetes security incidents. Not vulnerabilities. Misconfigurations.

The Runtime and Infrastructure Layer is where excessive privileges, weak isolation, or exposed cloud identities let attackers persist well beyond the initial compromise. Privileged containers, mounted Docker sockets, and exposed metadata services all create pathways from container to host.

The real danger emerges when failures align across multiple layers at once. A vulnerable image deployed with excessive RBAC permissions in a namespace without network policies creates a compound risk that no single point-control can address. I’ve seen this exact scenario in production environments more than once.

Anatomy of a Container-to-Host Pivot

Let me walk you through how attackers actually move from a container foothold to owning your infrastructure. It’s not theoretical. These are documented attack paths that red teams and threat actors follow routinely.

The Attack Chain

Stage 1: Initial Compromise. The attacker gets into a container. This could happen through an application vulnerability like SSRF or remote code execution, a supply chain attack through a poisoned base image, compromised CI/CD dependencies, or simply stolen credentials.

Stage 2: Enumeration. Once inside, the attacker starts probing for misconfigurations. They’re looking for mounted Docker sockets, excessive Linux capabilities like CAP_SYS_ADMIN or CAP_SYS_MODULE, accessible cloud metadata endpoints, exposed service account tokens, and writable host filesystem mounts. A few quick commands tell them everything they need to know:

id                     # Am I running as root?
cat /proc/1/status     # What capabilities do I have?
mount                  # Any dangerous volumes mounted?
cat /proc/self/cgroup  # Confirm I'm in a container

Stage 3: Container Escape. This is where the attacker breaks out. Depending on what they found during enumeration, they’ll use capability abuse, Docker socket exploitation, host path manipulation, or a runtime vulnerability to execute code on the host. I’ll cover the specific techniques in detail below.

Stage 4: Privilege Escalation and Lateral Movement. With host access, the attacker escalates to root, steals cloud credentials from the Instance Metadata Service, accesses other containers, and pivots to broader infrastructure. Databases, storage buckets, CI/CD pipelines, corporate networks. Everything is on the table.

Stage 5: Persistence and Exfiltration. The attacker deploys hidden DaemonSets, injects malicious container images, alters ConfigMaps, or sets up reverse shells. Data gets staged in cloud storage within the victim’s own tenant before being exfiltrated externally.

Key Escape Techniques

Container escapes exploit different layers of the containerisation stack. MITRE ATT&CK catalogues this under Technique T1611, Escape to Host. Here are the primary vectors:

Privileged Container Abuse is the most straightforward path. Containers running with the --privileged flag or excessive Linux capabilities like CAP_SYS_ADMIN and CAP_SYS_MODULE can interact directly with host resources. With CAP_SYS_MODULE, an attacker can load malicious kernel modules that execute code at the kernel level on the host. It’s essentially handing them the keys and saying “do whatever you want.”

Docker Socket Mounting remains disturbingly common, especially in CI/CD pipelines. When /var/run/docker.sock gets mounted inside a container, an attacker can interact with the Docker daemon to create new privileged containers, mount host filesystems, and gain full host access. The attack is simple:

docker -H unix:///var/run/docker.sock run -v /:/host --privileged -it alpine chroot /host sh

That one command spawns a new privileged container with the entire host filesystem mounted, then chroots into it. Game over.

CVE-2025-9074 showed that even without explicitly mounting the socket, Docker Desktop containers could access the Docker Engine API via the default subnet. That vulnerability bypassed Enhanced Container Isolation settings entirely.

Host Path Mounts are another frequent offender. Containers configured to mount host directories (especially /, /etc, or /var) give direct read/write access to host filesystems. From there, attackers modify host configuration files, plant SSH keys, or alter cron jobs for persistent access.

Kernel Exploitation is possible because containers share the host kernel. CVE-2022-0492, a cgroups release_agent flaw, allowed container escape and full node takeover. Any kernel vulnerability exploitable from within a container’s syscall surface is fair game.

The runc Vulnerabilities of November 2025 deserve special attention. Three high-severity CVEs (CVE-2025-31133, CVE-2025-52565, and CVE-2025-52881) were disclosed that enabled full container breakouts. CVE-2025-31133 exploited masked path abuse through mount race conditions. CVE-2025-52565 used symlink replacement to exploit /dev/console bind-mount flaws. CVE-2025-52881 bypassed Linux Security Module checks through procfs write redirects, enabling host crashes or complete breakouts. Because runc is the default low-level runtime for Docker, Podman, and Kubernetes, the blast radius was enormous. These could be triggered from containers using custom mount configurations, including those defined in Dockerfiles.

The NVIDIA Container Toolkit Vulnerability (CVE-2025-23266) demonstrated a “Confused Deputy” attack where privileged GPU container processes could be tricked into executing malicious code. This was particularly concerning for organisations running AI workloads, as it enabled access to model weights, training datasets, and broader cloud infrastructure.

Lateral Movement After Escape

Once an attacker has broken out of the container and landed on the host, the real damage begins. They steal kubelet configurations at /var/lib/kubelet/kubeconfig or service account tokens, then use kubectl to enumerate the entire cluster. From there, they can deploy DaemonSets for cluster-wide persistence, deploy cryptominers, move pod-to-pod through flat networking where no NetworkPolicies exist, or pivot into cloud infrastructure via IMDS credentials.

The Misconfigurations That Make All of This Possible

These attack chains don’t succeed because of brilliant hacking. They succeed because of configuration decisions that seemed harmless at the time.

Overly Permissive RBAC and Service Accounts

Kubernetes RBAC misconfigurations are among the most frequently exploited weaknesses in production. The pattern is always the same: roles granting wildcard (*) verbs or broad resource access make it trivial for attackers to pivot once they get initial access.

Here’s a common pitfall I’ve come across repeatedly. Kubernetes auto-mounts a default service account token into every pod. If that behaviour isn’t explicitly disabled, it grants unintended API access. Attackers actively hunt for these tokens on compromised containers.

The typical failure patterns include unbounded ClusterRoleBindings with excessive cluster-wide rights, copy-paste RoleBindings reused across namespaces without scoping, and reliance on default service accounts that carry far more privilege than anyone realises.

In one documented attack path, an attacker authenticated as the default service account, listed all ConfigMaps to extract stored database credentials and API keys, then deployed a malicious pod with host path mounts to complete the cluster takeover. That entire chain started with a service account token that nobody thought to restrict.

Azure’s managed Airflow service hit this problem in late 2024. RBAC weaknesses in the underlying Kubernetes environment risked cluster-wide breaches, including root VM access and compromised Azure resources.

Privileged Containers and Missing Security Contexts

Running containers as root or with the --privileged flag provides a direct pathway from container to host. Everyone knows this. And yet it remains pervasive in production. Why? Because dev environments get promoted to production without security review. Because “it works with privileged mode” becomes the path of least resistance.

The absence of proper security contexts, specifically failing to set runAsNonRoot: true, allowPrivilegeEscalation: false, and readOnlyRootFilesystem: true, leaves containers in an unnecessarily dangerous default state.

Missing or Permissive Network Policies

By default, all pods in a Kubernetes cluster can talk to each other. Every pod. Every namespace. No restrictions. This flat network architecture is a massive security liability.

Without NetworkPolicies enforcing micro-segmentation, lateral movement from one compromised container to databases, internal APIs, and other sensitive services is completely trivial. An attacker just scans the network, finds interesting services, and starts connecting.

Exposed Cloud Metadata Services

This one keeps coming up. The Instance Metadata Service runs on every major cloud provider’s compute platform at 169.254.169.254. It returns IAM role credentials, access keys, session tokens, and other sensitive information. When containers can reach this endpoint, and they can by default in most configurations, any SSRF vulnerability or RCE in a containerised application becomes a direct path to cloud account credentials.

The Capital One breach in 2019 remains the textbook example. A misconfigured web application firewall allowed SSRF requests to the IMDS endpoint, and an attacker exfiltrated over 100 million customer records from S3. That breach cost Capital One over USD 80 million in fines and fundamentally changed how cloud providers handle metadata service security.

AWS IMDSv2 mitigates most SSRF-based attacks by requiring a session token obtained via a PUT request with custom headers. But enforcement is inconsistent. As of 2025, 81% of EKS clusters still relied on deprecated CONFIG_MAP authentication. That’s a sobering number.

Exposed Docker Daemon and API Server

Tesla’s breach came through an unsecured Kubernetes dashboard exposed to the internet with no authentication. Qualys TRU research uncovered Docker daemon ports left open in production, usually carried over from development habits that nobody cleaned up before going live.

Insecure Secret Management

Storing API keys, database passwords, and cloud credentials directly in ConfigMaps, environment variables, or baked into container images is still shockingly widespread. A vulnerability in an Azure File CSI driver (CVE-2024-3744) leaked Kubernetes secrets in log files.

The ShadowV2 botnet campaign, discovered in June 2025, targeted misconfigured Docker containers on AWS specifically, deploying Go-based malware that turned infected systems into DDoS attack nodes. The campaign’s command-and-control infrastructure was hosted on GitHub Codespaces, which shows just how creative attackers are getting with legitimate developer platforms.

Vulnerable and Unverified Container Images

With 87% of production images carrying high or critical vulnerabilities, the image layer is a foundational risk. Supply chain attacks are growing fast. Attackers poison base images and dependencies upstream, then wait for CI/CD pipelines to pull the compromised artifacts automatically.

The November 2025 runc vulnerabilities exemplified the systemic nature of this risk. Because runc is the default runtime for essentially the entire container ecosystem, a single set of vulnerabilities had implications everywhere.

Real-World Incidents That Prove the Point

Theory is one thing. Let’s look at what actually happened.

Tesla Kubernetes Dashboard Breach

Attackers found Tesla’s Kubernetes dashboard exposed to the internet without any authentication. They deployed cryptojacking containers using custom Docker images and non-standard ports to avoid detection. One misconfigured dashboard led to resource hijacking across an entire cluster.

Capital One SSRF-to-IMDS Pivot (2019)

A misconfigured WAF allowed SSRF requests to the EC2 Instance Metadata Service. The attacker extracted temporary IAM credentials and used them to access over 100 million customer records from S3 buckets. The USD 80 million fine was just the financial cost. The reputational damage was incalculable.

Azure AKS TLS Bootstrap Attack (2024)

Researchers found a privilege escalation path in Azure Kubernetes Service where attackers could use Azure WireServer to retrieve keys for decrypting protected settings. This exposed provisioning scripts containing critical authentication information. It was a reminder that managed Kubernetes services can introduce unexpected attack vectors through their own implementation details.

ShadowV2 Botnet (2025)

This campaign predominantly targeted misconfigured Docker containers on AWS. Go-based malware turned compromised containers into DDoS-for-hire nodes. The use of GitHub Codespaces for command and control was a clever abuse of a legitimate platform.

The runc Container Breakout Trio (November 2025)

Three high-severity vulnerabilities that enabled full container breakouts across Docker, Podman, and Kubernetes. Masked path abuse, /dev/console bind-mount flaws, and LSM check bypasses. All exploitable through containers with custom mount configurations, including those defined in standard Dockerfiles.

OpenMetadata Exploitation (2024)

Threat actors exploited critical vulnerabilities in OpenMetadata, including SpEL injection and authentication bypass with CVSS scores between 8.8 and 9.8, to compromise Kubernetes workloads for cryptocurrency mining. Application-layer vulnerabilities in orchestration tooling leading directly to full container environment compromise.

Key CVEs You Should Know About

Here’s a quick reference of the most significant container-related vulnerabilities from recent years:

• CVE-2019-5736 (2019): runc vulnerability enabling host binary overwrite and root-level code execution from within a Docker container.
• CVE-2022-0492 (2022): Linux kernel cgroups release_agent flaw allowing container escape and full node takeover.
• CVE-2023-2640 / CVE-2023-32629 (2023): OverlayFS vulnerabilities enabling privilege escalation from non-root containers through volume mount manipulation.
• CVE-2024-21626 (2024): High-severity runc container escape via unsafe prctl call, bypassing no_new_privs sandboxing.
• CVE-2024-10220 (2024): Kubernetes gitRepo volume vulnerability allowing arbitrary command execution beyond container boundaries.
• CVE-2025-1974 (2025): IngressNightmare. Critical unauthenticated RCE in the Kubernetes Ingress-NGINX Controller via malicious ingress object injection.
• CVE-2025-9074 (2025): Docker Desktop vulnerability allowing containers to access the Docker Engine API via internal subnet.
• CVE-2025-23266 (2025): NVIDIA Container Toolkit Confused Deputy attack enabling container escape to access AI model weights and cloud infrastructure.
• CVE-2025-31133 / 52565 / 52881 (2025): The runc container breakout trio. Procfs write bypass, /dev/consolemount races, and LSM check bypass enabling full host access.

Defence Strategies and Hardening Recommendations

Fixing this isn’t about buying one product or flipping one switch. It requires a layered approach that covers the entire container lifecycle.

Image Security and Supply Chain Integrity

Start at the foundation. Use minimal base images like Alpine or distroless to cut down on inherited vulnerabilities. Scan container images in your CI/CD pipeline before anything reaches production, and block deployments that carry critical or high-severity CVEs.

Sign every container image using Sigstore or Cosign and enforce image provenance checks through admission controllers. Use hardened internal registries and verify all pulls from external sources. Generate and maintain Software Bills of Materials for all production images.

One thing people miss: scan your running containers too, not just the images in the registry. Runtime drift is a leading breach vector.

RBAC and Access Control Hardening

Apply least privilege to every Kubernetes account. Audit your Roles and ClusterRoles and eliminate wildcard permissions. Disable auto-mounting of default service account tokens by setting automountServiceAccountToken: false on pods that don’t need API access.

Use separate service accounts per workload with scoped permissions. Treat RBAC as code. Test it, validate it, monitor it continuously. Rotate tokens regularly and use short-lived tokens wherever possible.

Pod Security and Runtime Hardening

Enforce comprehensive security contexts on every container:

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]
  seccompProfile:
    type: RuntimeDefault
resources:
  limits:
    cpu: "200m"
    memory: "256Mi"

Use Pod Security Standards with the Restricted profile, or deploy OPA Gatekeeper or Kyverno to block non-compliant workloads at admission time. Never run containers with the --privileged flag in production. Never mount Docker sockets or host paths into containers.

Network Segmentation

Define explicit NetworkPolicies for every namespace. Start with default-deny for both ingress and egress, then whitelist only the communication paths your workloads actually need. Separate workloads into distinct namespaces by sensitivity and function.

Deploy WAF protections on ingress controllers. Use service mesh encryption with mTLS for all inter-service communication. And monitor east-west traffic for anomalies that might indicate lateral movement.

Cloud Metadata Service Protection

Enforce IMDSv2 on all AWS EC2 instances and disable IMDSv1 entirely. Use network policies or firewall rules to block container access to 169.254.169.254 wherever it isn’t explicitly required.

Where possible, prefer serverless container platforms like AWS Fargate, which use the Container Metadata Service with dynamic credential endpoints. The barrier to credential theft is significantly higher on Fargate compared to traditional EC2-backed nodes.

Audit IAM roles attached to your Kubernetes nodes and apply least-privilege principles to instance profiles.

Secret Management

Stop putting secrets in ConfigMaps and environment variables. Use external secret managers like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault. Automate secret rotation because manual rotation policies don’t scale.

Encrypt all secrets at rest in etcd. Never mount secrets cluster-wide. Keep them workload-scoped. Scan your repositories and container images for hardcoded credentials.

Runtime Detection and Incident Response

Deploy eBPF-based runtime detection tools like Falco, Tetragon, or Tracee to catch anomalous system calls, unexpected process execution, and container escape indicators in real time.

Build automated forensics pipelines. Traditional incident response falls apart with ephemeral infrastructure where evidence can vanish in seconds. Monitor for specific indicators: unauthorised curl or wget operations, reverse shell establishment, unexpected privilege escalation, and anomalous Kubernetes API calls.

Enable comprehensive Kubernetes audit logging with adequate retention periods.

Advanced Isolation for High-Risk Workloads

For your most sensitive workloads, standard container boundaries might not be enough. Consider:

gVisor runs a user-space kernel that intercepts every system call, eliminating direct host kernel interaction. It integrates with major cloud providers and can be selectively deployed where you need the strongest isolation.

Kata Containers provides lightweight VM-based isolation for each container, giving you the speed of containers with the security boundary of hardware virtualisation.

Rootless containers with user namespaces map the container root to an unprivileged host user, dramatically reducing the impact of any container escape.

What’s Coming in 2026 and Beyond

A few trends are shaping where this space is heading.

Adversaries are using AI to scan Kubernetes clusters for misconfigurations at machine speed, chain privilege escalation paths automatically, and generate polymorphic container malware that evades both static and behavioural detection. The asymmetry between attack speed and defence speed is widening.

Exploitation windows are collapsing. Google observed threat actors deploying cryptominers within 48 hours of public CVE disclosure in late 2025. The window between “vulnerability disclosed” and “actively exploited in the wild” is shrinking fast.

Supply chain attacks are becoming the primary vector. The most devastating breaches of 2025 and 2026 came through containers, not networks. Attackers infect upstream by poisoning base images and dependencies, then wait for CI/CD pipelines to do the distribution for them.

On the positive side, cloud providers are moving toward secure-by-default configurations. Google’s success in reducing misconfiguration-based initial access from 29.4% to 21% shows the impact of this approach. By 2027, automated remediation is expected to handle 80% of common misconfigurations. And AI-assisted vulnerability prioritisation is helping enterprises move beyond raw CVE counts toward contextual risk assessment.

Wrapping Up

Misconfigured containers are not a hypothetical risk. They are the most common pivot point from a single workload to full infrastructure compromise. The attack chains are well-documented, the tools are freely available, and threat actors are executing them faster than ever.

But here’s the good news: most of these exploits are preventable. Explicit security contexts, enforced policies, locked-down RBAC, network segmentation, protected metadata services, and runtime monitoring address the vast majority of the risk.

The organisations that will weather this threat landscape are the ones treating security as a continuous, automated process across every layer of the container lifecycle. Not a checkbox before deployment. Not a quarterly review. A living, enforced, monitored posture that assumes every container could be hostile until proven otherwise.

Start with the basics. Enforce least-privilege defaults at every layer. Treat RBAC and network policies as code. Harden your metadata services. Invest in runtime detection that can keep up with ephemeral infrastructure. And for your highest-risk workloads, consider the advanced isolation technologies that put a real boundary between containers and hosts.

The attack surface isn’t shrinking. But your exposure to it absolutely can.