Share of operators scanned that Unit 42 says request excessive privileges, beyond the two case studies (base not disclosed): Slightly over 5% (Source: Palo Alto Networks Unit 42 (September 29, 2026))
A helper with a key and no job description
A firm would ask a contractor with a master key what the job is. Some software helpers inside Kubernetes hold broad access with no such question asked.
Kubernetes is the system many firms use to run their applications. An operator is an automated helper inside it. It watches a service, such as a database, and handles routine fixes without waiting for a person.
Palo Alto Networks' Unit 42 team published research on these helpers on September 29. Its main point is that an operator's permissions set the scope of any compromise. How the attacker got in matters less.
For executives, the lesson is to read the permission list. It shows what a compromise of that software would reach.
What Unit 42 built and measured
Unit 42 released OperTraitor, an open-source tool that uses a large language model. It reads an operator's access rules and compares them with what its documentation says it does. It then gives a risk score from 1 to 10.
The team fed it data from OperatorHub, a public catalog of operators, and from locally installed operators.
Unit 42 does not say how many operators it tested. It also does not say how the share splits between OperatorHub and local installs. The report does not name the base for the percentage. Read it as the result of Unit 42's own tool, not as an industry-wide rate.
Unit 42 adds that some of these operators offer an indirect route to full cluster admin rights.
The team also found old versions sitting on OperatorHub. Many vendors now publish secure new versions elsewhere, such as Helm charts, GitHub or ArtifactHub. The older versions stay listed. Users can install them in a few clicks, often without knowing they are outdated.
Many owners did not reply to Unit 42's disclosure attempts. Unit 42 says that often means the operator is no longer maintained.
Two vendors, two different answers
The first case involved Prometurbo, an operator in IBM's Turbonomic platform. The OperatorHub copy was version 8.6.0, from 2022. Unit 42 then checked version 8.17.6 on IBM's GitHub to see if the setup had changed. The tool still flagged a problem.
The operator's service account was tied to a cluster-wide role. That role let it read secrets in every part of the cluster. Unit 42 said an attacker could pull tokens, database credentials, API keys and certificates from unrelated areas. One contained breach could then spread to the whole environment.
IBM responded promptly, according to Unit 42. It fixed the problem in a later release that narrowed the operator's permissions. IBM also published a security bulletin and CVE-2026-6389. That CVE covers this permissions flaw in Turbonomic.
The timeline is short. Unit 42 reported the flaw on November 5, 2025. IBM confirmed the fix on February 3, 2026. The bulletin followed on April 24, 2026.
The second case was the Datadog operator. OperTraitor flagged cluster-wide access to secrets and broad actions on access-control resources. Datadog explained that secret names depend on values users define, so it cannot list them in advance. Unit 42 called that a fair point about the trade-off between strict security and easy setup.
Datadog added documentation of its access settings and the mitigations it applies. That lets customers decide whether to accept the risk. Broad access, openly explained, is a choice a buyer can weigh.
Why the AI angle matters here
Unit 42 says the industry is moving toward agentic operators. These are systems that manage clusters using AI reasoning. In its view, broad permissions become a more serious weakness once an AI system holds them.
That is Unit 42's assessment of an emerging pattern, not a measured result. The tool also relies on a language model. Its scores are a starting point for review, not a verdict.
The defensive advice is the same either way. Unit 42 says to secure the service account, whether the operator uses AI or ordinary logic.
Questions to put to your platform team
Ask how many operators run in your clusters and who owns each one. Ask which of them can read secrets across the whole cluster. Ask where each was installed from, and whether that source is still maintained.
Unit 42 offers practical steps. Do not trust old versions from default registries such as OperatorHub. Prefer a vendor's maintained Helm chart or official repository. Limit operators to the areas they manage. Check the vendor's access files before deployment, and re-check them for critical production systems.
Also ask for a written reason whenever an operator needs broad access. Datadog shows that such a reason can exist and can be shared. A permission you can explain is one you can decide on.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Palo Alto Networks Unit 42.
