An IBM Turbonomic Prometurbo operator could read Kubernetes secrets across a cluster, including secrets outside the namespaces it managed. Unit 42 researcher Lior Yakim found the operator’s service account bound to a ClusterRole with get, list and watch on secrets. A compromise of that operator or its service account could turn access to one workload into access to credentials used elsewhere in the cluster.
IBM’s record for CVE-2026-6389 identifies Prometurbo agent 8.16.0 through 8.17.6 as affected and names 8.18.0 for reinstallation with the required fixes. The vulnerable permission offers a route to wider compromise after an attacker compromises the operator or its service account. Investigate account activity separately from the permission grant. IBM credits Yakim with the finding.
A service account reaches every namespace
A Kubernetes operator watches custom resources and continually reconciles them with the desired state. It uses a service account to call the API server. Kubernetes RBAC documentation distinguishes a namespaced RoleBinding from a ClusterRoleBinding, which grants the referenced role across the cluster. Prometurbo’s binding gave its service account cluster-wide read access to secrets in the core API group (apiGroups: [""]). That includes the get, list and watch verbs, according to Unit 42.
A secret in an unrelated namespace might hold a database password, API key or service-account credential. A controller that needs one application secret should not receive a key to every namespace’s secret store. IBM’s CVE description says an attacker who compromises the operator or its service account can exfiltrate credentials and escalate privileges, potentially reaching full cluster compromise. Yakim calls the resulting cluster-wide exposure “a single point of failure.”
Unit 42 first found wildcard permissions in the OperatorHub entry for Prometurbo 8.6.0, dated to 2022, then examined IBM’s more recent GitHub version 8.17.6 and found the cluster-wide secret permission. IBM’s CVE affected range starts at 8.16.0: treat the old catalog listing as a reason to inspect the version you deploy, and match installed agents to the recorded affected range rather than extending the CVE to that earlier listing. IBM responded to the disclosure and scoped the agent permissions in a subsequent release, Unit 42 reports.
Other operators expose different trade-offs
Unit 42’s OperTraitor compares an operator’s documented function with the RBAC granted by its manifests. The research team says slightly over 5% of the operators it examined requested excessive privileges, including paths to cluster-admin access. Use that research sample as a prompt to inspect the bindings of operators actually installed in your cluster. OperatorHub may also retain older packages after vendors ship newer operators through maintained channels.
The researchers also flagged the Datadog operator for cluster-wide secret reads and verbs on ClusterRoles and ClusterRoleBindings. Datadog told Unit 42 that users choose secret names at deployment time, making a fixed list impractical for its architecture. Datadog documented its RBAC choices and mitigations after disclosure. That explanation changes the review: compare permissions with the deployment’s requirements and the vendor’s documented mitigations before changing a dynamic operator’s binding. Unit 42’s research evaluates operator security, and its own OperTraitor tool and Palo Alto Networks services are among the products it recommends.
The AI angle is prospective. Unit 42 warns that LLM-enhanced controllers and external agent bridges inherit the same service-account permissions. The same broad binding exposes secrets whether an ordinary controller or an LLM-enhanced one uses the service account.
Reinstall and test effective permissions
Start with the Prometurbo agent version deployed in each cluster. For an installed 8.16.0 through 8.17.6 agent, follow IBM’s instruction in its CVE record to reinstall a version with the required fixes, naming 8.18.0. Inspect the deployed manifests and bindings after installation, since a running controller and its service account are what the API server authorizes. For other operators, compare their installed manifests with the vendor’s maintained release and document which namespaces and secrets each one genuinely needs before narrowing permissions.
With the service account name and namespace from the installed workload, test its effective authorization from an account permitted to impersonate it:
kubectl auth can-i list secrets --all-namespaces --as=system:serviceaccount:OPERATOR_NAMESPACE:OPERATOR_SERVICE_ACCOUNT
kubectl auth can-i get secrets -n OTHER_NAMESPACE --as=system:serviceaccount:OPERATOR_NAMESPACE:OPERATOR_SERVICE_ACCOUNTSubstitute real names and a namespace outside the operator’s intended scope. These are authorization queries, not secret-read requests. A yes on an unrelated namespace merits a binding review; for a namespace-scoped operator after downscoping, the expected result is no there. Inspect ClusterRoleBindings, RoleBindings and their referenced roles when the result differs from the intended scope. The test requires impersonation rights, so use a trusted cluster administrator rather than changing the operator’s privileges to run it.
Keep operator identities within scope
Cluster administrators can remove Prometurbo’s cluster-wide secret access by reinstalling the fixed agent and verifying the service account’s effective permissions in an unrelated namespace. For other controllers, change the bindings that exceed their documented requirements; review any cluster-wide grant and keep only resources and verbs needed for their job. Watch Kubernetes API audit events for an operator service account listing secrets outside its working namespace or calling the API from an unexpected address, as Unit 42 advises. Those events can show unusual use of an existing grant; a quiet log period is not a substitute for removing that grant.
After remediation, the Prometurbo operator should still reconcile its intended resources while its service account receives no for secret reads outside its authorized scope.