An attacker compromised 60+ Kubernetes clusters in a single campaign without exploits, zero-days, or CVEs. Entry came through an API server running anonymous authentication. The attacker read existing RBAC bindings and let the cluster's own configuration deliver cluster-admin access.
The blast radius of a Kubernetes cluster is determined in the first 5 minutes after any foothold. The API server, RBAC bindings, and service account token automounting define the escape path before a single exploit is needed. In real incidents, the exploit comes last. Configuration already decided the outcome.
The Exploit Comes Last — Configuration Decides the Outcome First
The RBAC Buster incident (Aqua Security, April 2023) compromised 60+ Kubernetes clusters without a single exploit. The attacker found API servers with --anonymous-auth=true, read existing RBAC bindings, and reached full control in an average of 3.2 minutes after initial access. The campaign generated 14,399 malicious image pulls over 5 months, all through configuration, none through vulnerability.
Tesla learned this directly in 2018. The Kubernetes dashboard was exposed without any authentication. The attacker read AWS S3 credentials directly from pod environment variables, deployed a cryptominer behind Cloudflare to mask traffic, and exited without any exploit trace. No CVE was filed because no CVE was needed.
The 2025 data confirms these were not isolated cases. Unit 42 recorded a 282% increase in Kubernetes token theft during the period. Azure Kubernetes Service clusters receive the first attack attempt 18 minutes after creation. The blast radius is not determined at the moment of the incident. It is determined at helm install.
Kubernetes versions from 1.25 improved defaults: PSS replaced PodSecurityPolicy, --anonymous-auth=false became the recommendation, and EKS and GKE Autopilot tightened factory settings. The blast-radius problem persists in clusters created before those changes, in self-managed deployments where operators overrode defaults for application compatibility — which Unit 42 found in 22% of audited cloud environments — and in any cluster where the attack vector is not a CVE but a ClusterRoleBinding created in 2019 that no one reviewed.
381,645 Entry Points: How the Exposed API Server Became Mass Exploitation Surface
The Shadowserver Foundation identified 381,645 unique IPs responding with HTTP 200 OK on Kubernetes ports 443 and 6443. That number represents 84% of all identifiable Kubernetes clusters on the internet. Automated scanning of that volume is operationally trivial for any threat actor with a basic infrastructure budget.
Censys documented 1,626,249 cluster hosts with visible version numbers in February 2024, more than double the 842,350 identified in August 2022. The /version endpoint returns version information without authentication in most configurations. With version in hand, attackers can select exploits targeting specific Kubernetes, runtime, or CNI versions.
The --anonymous-auth=true flag is the Kubernetes default. It automatically grants membership in the system:anonymous and system:unauthenticated groups, groups that downstream RBAC rules can amplify into concrete read or write permissions. A curl -k https://[IP]:6443/api/v1/pods returns a pod list in misconfigured clusters without any credentials presented.
etcd Port 2379: Bypassing the API Server and All Its Controls at Once
etcd stores the entire Kubernetes cluster state: pod environment variables, ConfigMap contents, Secret values in base64, TLS certificates, and service account tokens. Direct access via port 2379 delivers everything simultaneously, bypassing the API server and any RBAC controls applied there.
From etcd's perspective, the API server is just another client. The entire Kubernetes access control model, including RBAC, admission controllers, and audit logging, disappears when the attacker accesses etcd directly. The official Kubernetes documentation is explicit: read access to etcd via client certificate is equivalent to cluster-admin.
CVE-2026-33413 (CVSS 8.8) quantifies the risk in unpatched clusters: unauthenticated users can invoke critical etcd backend methods via the gRPC endpoint on port 2379 without administrative tokens. Self-managed clusters with etcd exposed without mutual TLS are targeted for complete secrets exfiltration or extortion over stored data.
Service Account Token Automounting: Any App Vulnerability Becomes a K8s Credential
Kubernetes automatically mounts service account tokens at /var/run/secrets/kubernetes.io/serviceaccount/token in all pods with automounting active, which is the default. Any process in the pod, from the main binary to a compromised third-party dependency, can read and use that token to authenticate against the Kubernetes API as the service account identity.
The cryptocurrency exchange incident documented by Unit 42 in mid-2025 followed this path exactly. A developer workstation compromise led to a malicious pod that read the token at the default path, gained cross-namespace access to cluster secrets, and reached financial backend systems without any container escape exploit at any point in the chain.
The scale of the problem is documented: 22% of cloud environments in 2025 showed suspicious SA token theft activity (Unit 42). The Azure Airflow RBAC misconfiguration in 2023 affected 350+ organizations, including Fortune 500 companies, via two common configuration errors that left clusters publicly accessible. MITRE ATT&CK tracks the vector as T1528, with a Kubernetes-specific technique. Any authorized file read in memory or filesystem converts application compromise into control plane compromise.
Over-Permission Chains in RBAC Complete the Escape Without Privilege Escalation Exploits
Stolen service account tokens frequently do not need additional exploits. The attacker follows the permission graph the operator built. In RBAC Buster, the strategy was to create a ClusterRole with near-administrative privileges bound to a ServiceAccount named kube-controller in the kube-system namespace, mimicking legitimate component naming to evade manual inspection of audit logs.
Binding cluster-admin to the default ServiceAccount in the default namespace distributes full cluster control to every pod in that namespace. Wildcard permissions with verbs: ["*"] and resources: ["*"] grant admin-equivalent access and appear consistently in self-managed clusters. No automatic alert fires on the creation of an overly permissive ClusterRoleBinding by default.
Red Hat research (2026) documented where tooling fails: RBAC linters analyze bindings individually and produce a false sense of security. Attackers reason over the full permission graph and identify escalation paths that per-binding analysis never detects. RBAC Buster added a dimension to this: the malicious ClusterRoleBinding survived intact after the anonymous access that enabled entry was disabled. The backdoor outlasted the original misconfiguration.
Detection at the API Layer: What Attackers Leave and What We Monitor
Shodan and Censys fingerprint Kubernetes API servers via ports 443 and 6443 continuously. The /version endpoint returns version without authentication in most configurations, delivering the exact patch level and enabling version-targeted exploit selection. Any 200 OK status on port 6443 without credentials is classified as an immediate high-severity finding.
For continuous passive monitoring of exposed Kubernetes API servers, etcd on port 2379, and dashboards on ports 8001/8443, intel.mago.team (MAGO team tool) maintains visibility without active scanning.
Kubernetes audit logs carry the most relevant signals: anonymous requests to /api/v1, ClusterRoleBinding creation, and SA token access originating from IPs outside the expected range. CVE-2024-21626 (runC, critical) extends the blast radius to the node level when privileged containers or hostPath mounts to /etc or /var/run/docker.sock are present, converting pod compromise into physical host compromise.
Most Kubernetes security programs invest in CVE patching and runtime monitoring. Both are necessary. Clusters that deliver cluster-admin in 3.2 minutes do so via a ClusterRoleBinding created during a pressured deploy, a token automounted since the first helm install, and an API server listening on port 6443 with defaults no one reviewed. Audit RBAC bindings with tools that analyze the full graph, disable automounting in pods that do not need API access, block port 2379 at the network layer, and confirm that /version returns 401 and not 200 from outside your VPC.
Top comments (0)