Loading story…
Palo Alto Networks Unit 42 warned that overly permissive Kubernetes operator RBAC configurations can turn a compromised operator service account into a cluster-wide backdoor. Its open-source OperTraitor tool uses an LLM to compare an operator’s documented function against permissions requested in RBAC manifests and assigns a risk score from 1 to 10. In a review of OperatorHub/OLM content, researchers found outdated or potentially abandoned operators and reported that slightly more than 5% requested excessive permissions, including indirect routes to cluster-admin access.
A case study identified CVE-2026-6389 (CVSS 8.8) in IBM Turbonomic’s Prometurbo operator, where cluster-wide secret-read access could expose credentials from unrelated namespaces; IBM has patched the flaw. Unit 42 also examined broad secret and RBAC-resource permissions in the Datadog operator, for which Datadog documented operational justifications and mitigating controls. Organizations should validate operator provenance, scope operators to required namespaces, reduce RBAC privileges, monitor audit logs, and apply network and permission guardrails—particularly as LLM-enabled and agentic operators increase the consequence of excessive access.
Map this exposure pattern across your cloud, code, and identities.
3 events from the most recent confirmed update back to the earliest known activity.
IBM published a security bulletin for CVE-2026-6389, the Prometurbo operator RBAC vulnerability.
IBM confirmed it had remediated the Prometurbo vulnerability by scoping the operator's RBAC permissions according to the principle of least privilege.
Researchers reported that IBM Turbonomic's Prometurbo operator had cluster-wide Secret read permissions that could expose credentials from unrelated namespaces if the operator were compromised. The issue was later assigned CVE-2026-6389 with a CVSS score of 8.8.
See where this exposure pattern shows up across your cloud, code, supply chain, and non-human identities.
1 reference tracked. Mallory keeps watching after this page renders.
Map 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
Red Hat disclosed **`CVE-2026-73269`**, a critical privilege-escalation flaw in the `cluster-curator-controller` component used by **OpenShift Multicluster Engine for Kubernetes**. The bug allows a tenant with only namespace-level access to create a crafted `ClusterCurator` resource whose `metadata.name` differs from `metadata.namespace`, triggering the controller to create a cluster-scoped `ClusterRoleBinding` and, in some cases, a `RoleBinding` in an arbitrary namespace. Those bindings can attach the tenant’s namespace-local `cluster-installer` service account to the powerful curator role, effectively breaking namespace isolation. Successful exploitation can elevate a local tenant to **cluster-wide privileges**, including access to and manipulation of secrets, management of cluster actions, and deletion of hosted clusters or node pools. The issue carries a **CVSS 3.1 score of 9.9** and affects `multicluster-engine/cluster-curator-controller-rhel9`. Red Hat advised organizations to apply vendor fixes and reduce exposure by restricting creation of `ClusterCurator` resources through RBAC, enforcing matching `metadata.name` and `metadata.namespace` with an admission controller, and reviewing permissions that allow creation of cluster-scoped resources.
Aug 13, 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