Loading story…
Amazon EKS access management and Pod Identity add IAM-native controls for granting cluster access and workload AWS permissions, but security research found they can create lateral-movement and privilege-escalation paths. An attacker who compromises an IAM principal with CreateAccessEntry and AssociateAccessPolicy permissions can create or alter an EKS access entry and potentially obtain Kubernetes cluster-admin access. EKS access policies combine cumulatively with legacy aws-auth ConfigMap mappings and Kubernetes RBAC bindings, complicating effective-permission reviews; even AmazonEKSEditPolicy, and in some cases AmazonEKSViewPolicy, may expose escalation or sensitive-data-disclosure opportunities.
Pod Identity introduces a node-local agent that supplies temporary AWS credentials to workloads, expanding the impact of node or pod compromise. A compromised hostNetwork pod may intercept plaintext traffic to the local agent endpoint and capture credentials issued to other pods on the same worker node. Organizations should audit both EKS API and Kubernetes RBAC authorization paths, limit access-entry administration, apply namespace-scoped and least-privilege permissions, protect kubelet pod-file access, and segregate untrusted workloads. IAM Roles for Service Accounts (IRSA), which uses projected service-account OIDC tokens to obtain role-specific STS credentials, remains an alternative where preventing node-local credential interception is a priority.
Get the actors, campaigns, and ATT&CK mapping behind it.
5 events from the most recent confirmed update back to the earliest known activity.
Wiz described how IAM principals with EKS access-entry and access-policy management permissions could grant themselves high-privilege Kubernetes access. It also showed that a compromised hostNetwork pod can intercept plaintext local Pod Identity Agent traffic and capture other pods' temporary IAM credentials on the same node.
Wiz reported that cumulative permissions across aws-auth, EKS access entries, access policies, and Kubernetes RBAC complicate access auditing. It also identified risks including theft of Pod Identity tokens from kubelet pod files and credential exposure through permissive default service-account associations.
AWS subsequently introduced EKS access management, including access entries and access policies that associate IAM users and roles with Kubernetes cluster access and permissions through the EKS API.
AWS introduced EKS Pod Identity as a mechanism for EKS workloads to obtain IAM permissions, using a node-level agent to retrieve temporary credentials for associated service accounts.
AWS introduced IAM Roles for Service Accounts (IRSA), enabling EKS pods to exchange Kubernetes service-account OIDC tokens for temporary, pod-specific IAM credentials through STS AssumeRoleWithWebIdentity.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
Get the adversaries, campaigns, and ATT&CK mapping behind this technique, with detections ready to deploy.
4 references tracked. Mallory keeps watching after this page renders.
kubernetes.io
Open sourcewiz.io
Open sourcewiz.io
Open sourceaws.amazon.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
New technical writeups highlighted how seemingly *read-only* Kubernetes permissions can be escalated into **remote code execution (RCE)** by abusing access paths to the **kubelet** API. Horizon3.ai detailed a technique where a service account granted `nodes/proxy` **GET** (often treated as “read-only” for monitoring/log access) can, if it also has network reachability to the kubelet, be leveraged to execute commands in pods on reachable nodes—an outcome the Kubernetes project has largely treated as **“working as intended”** rather than a traditional vulnerability. The post emphasizes that this can translate into broad cluster compromise in many real environments and points to mitigations such as tightening RBAC and adopting controls aligned with **KEP-2862** and vendor RBAC hardening guidance. Separately, a bug-bounty case study described an end-to-end **cloud-native kill chain** culminating in Kubernetes takeover: an initial **SSRF** in a microservice was used to access **EC2 instance metadata** and steal cloud credentials, which then enabled kubelet API abuse to deploy a rogue privileged pod. From that foothold, the attacker obtained a more powerful Kubernetes service account token and escalated to `cluster-admin`, resulting in full cluster control and a reported **$100,000** responsible disclosure payout. While the initial access vectors differ, both accounts reinforce that kubelet exposure plus permissive RBAC/service-account design can turn “limited” access into cluster-wide impact, making kubelet reachability and `nodes/proxy`/kubelet-related permissions high-priority review items for Kubernetes security programs.
Jun 29, 2026
Two newly disclosed Kubernetes vulnerabilities show how limited access can escalate into broad secret theft and potential full-cluster compromise. **CVE-2026-39961** affects the Aiven Operator and enables cross-namespace secret exfiltration through a confused deputy condition, breaking multi-tenancy and namespace isolation. An attacker starting from a constrained developer role could access high-value service account tokens, particularly in `kube-system`, and potentially obtain `cluster-admin` privileges. From there, they could deploy malicious DaemonSets, alter node settings, read cluster-wide data, and pivot into cloud environments through permissive IAM integrations such as AWS IAM Roles for Service Accounts.
Jun 29, 2026
Palo Alto Networks Unit 42 disclosed a dual privilege-escalation chain in **Google Kubernetes Engine (GKE)** that could let an attacker with limited access gain broader control inside Kubernetes environments. The attack path combined weaknesses in monitoring-related configuration and service mesh privileges, allowing unauthorized access to cluster resources and creating a route from a constrained foothold to elevated permissions. The reported chain involved **Fluent Bit** and **Anthos Service Mesh** components, showing how overly permissive configurations and inherited privileges in managed Kubernetes deployments can be linked together for escalation. The findings highlight the risk of misconfigured observability and mesh tooling in cloud-native environments, where service accounts, cluster roles, and add-on integrations can expand an attacker’s reach beyond the initial compromise if not tightly scoped.
Jul 12, 2026