Palo Alto Networks’ Unit 42 has published research on how Kubernetes operators, the controllers that automate cluster tasks, quietly hold far more access than their documentation says. In a report dated September 29, researcher Lior Yakim describes OperTraitor, an open-source tool that uses a large language model to compare an operator’s stated function with the RBAC permissions it is actually granted, then scores the gap from 1 to 10.
Unit 42 says it ran the tool across OperatorHub and locally installed operators and found that slightly over 5% request excessive privileges, including implicit paths to cluster admin. One case became CVE-2026-6389, a High-severity flaw (CVSS 8.8) in IBM’s Turbonomic platform, where the Prometurbo operator’s service account could read secrets cluster-wide. Unit 42 says IBM fixed it and published a bulletin on April 24, 2026. A second case, the Datadog operator, held broad secrets and RBAC access for a stated reason: the secret names are user-defined and cannot be predicted in advance. Datadog documented the trade-off instead of removing it.
Why it matters
An operator’s service account defines the damage if the operator is compromised, whether through a poisoned image, a vulnerable dependency or a hijacked node. Unit 42 also reports that older, weaker versions of operators stay installable through OperatorHub after vendors publish newer ones elsewhere, and that many owners did not answer disclosure attempts.
One original angle
These are non-human identities, and they get less review than a human admin account. We made a similar point when forgotten service accounts let attackers into Microsoft 365, and a leaked cloud credential drove the destruction described in the JadePuffer Azure attack. Add operators to your identity inventory, prefer namespace-scoped installs, and check the version you install against the vendor’s own repository.
Source: Palo Alto Networks Unit 42
