Kubernetes operators, the small controllers that automate running databases, monitoring agents and other software inside a cluster, are routinely handed far more access than they need. Researcher Lior Yakim of Palo Alto Networks' Unit 42 says in the original report that slightly over 5% of the operators the team examined request excessive privileges, including implicit paths to full cluster-admin access. If any one of them is compromised, through a poisoned container image, a vulnerable dependency or a hijacked node, the attacker inherits everything that operator is allowed to touch.
To measure the problem, Unit 42 built and open-sourced OperTraitor, a tool that pulls the role-based access control (RBAC) rules from locally installed operators and from the OperatorHub catalog, feeds them to a large language model, and compares what each operator is granted against what its documentation says it does. It then scores the gap from 1 to 10.
Old, over-privileged versions are still one click away
The sharpest finding is about where people get operators. Many vendors now ship new, tighter versions only through Helm charts, GitHub or ArtifactHub, while their older, more permissive releases stay available through the Operator Lifecycle Manager, the long-standing default in OpenShift environments. Users can deploy an outdated operator in a few clicks without realising it. Unit 42 says many of the operator owners it contacted never replied, which in many cases suggests the operator is simply no longer maintained.
IBM's Prometurbo could read every secret in the cluster
OperTraitor first flagged IBM's Prometurbo operator, used by IBM Turbonomic, because the OperatorHub copy was a v8.6.0 build from 2022. Checking the current v8.17.6 release on IBM's GitHub, Unit 42 found its service account bound to a ClusterRole granting get, list and watch on Secret objects across the whole cluster, not just its own namespace. Unit 42 says an attacker who compromised the operator could have dumped service account tokens, database credentials, API keys and TLS certificates from unrelated namespaces. IBM confirmed a fix in February and published a security bulletin in April assigning CVE-2026-6389, rated CVSS 8.8.
Datadog's operator was flagged for cluster-wide secret access and rights over ClusterRoles and ClusterRoleBindings. Datadog told the researchers the secret names depend on user-defined values and cannot be predicted in advance, so it kept the permissions and documented them instead. Unit 42 treats that as a genuine trade-off between security and usability rather than a bug.
Why AI raises the stakes
The report's wider warning is about agentic operators, which use LLMs to decide what to change in a cluster, or act as bridges for external AI agents through protocols such as Model Context Protocol. An operator that already holds broad RBAC rights would hand that reach to software whose behaviour is harder to predict. Unit 42's point is that the fix is the same either way: lock down the service account.
Scope operators to their namespace and audit what they hold
Unit 42 recommends:
- installing operators from the vendor's maintained Helm charts, ArtifactHub or GitHub rather than trusting the OperatorHub or OLM copy;
- scoping operators to the namespaces they manage and avoiding ClusterRoles and ClusterRoleBindings unless truly required;
- reviewing vendor RBAC manifests before deployment and downscoping them, with OperTraitor or similar tools;
- baselining operator service accounts in Kubernetes audit logs and alerting on anomalies, such as an operator listing secrets in an unrelated namespace;
- keeping LLM-driven operators off the public internet and limiting the context and permissions passed to the model.
Teams that run Turbonomic should confirm they are on a release that includes IBM's fix. Everyone else has an easier question to ask of each operator in their clusters: does it really need to read every secret we have? It is the same lesson as the cross-tenant Kubernetes storage flaws IntelFusions covered earlier: in a shared cluster, one component's reach is everyone's exposure.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.