IBM Turbonomic prometurbo CVE-2026-6389

Requires prior compromise of the IBM Turbonomic prometurbo operator pod OR theft of its Kubernetes ServiceAccount token (e.g., via exposed kubeconfig, etcd backup access, or node compromise). The excessive ClusterRole permissions are present in default deployments of prometurbo 8.16.0-8.17.6 installed via Helm charts or operator deployment manifests following IBM's standard installation procedures. Exploitation does NOT require: custom RBAC configuration changes by administrators, non-default Kubernetes features, or physical access to cluster nodes. Limits on exploitation: attacker must have network connectivity to the Kubernetes API server (typically restricted to cluster internal network), and Kubernetes RBAC must be enabled (disabled RBAC is extremely rare in production). Detection is feasible via Kubernetes audit logs monitoring 'list/get' operations on secrets resource by the prometurbo ServiceAccount, but many organizations do not have comprehensive audit logging configured.

Real-world risk is HIGH for organizations running affected prometurbo versions in multi-tenant or production Kubernetes clusters. The CVSS vector (AV:L/AC:L/PR:L/UI:N/S:C) indicates local access with low complexity and low privileges required, but the scope change elevates impact to cluster-wide confidentiality, integrity, and availability compromise. The 'local' attack vector (AV:L) in this context means an attacker needs initial access to the Kubernetes cluster - either through compromising the prometurbo pod itself (via container escape, supply chain attack, or vulnerable dependency) or stealing its ServiceAccount token. Once achieved, exploitation is straightforward using standard kubectl commands against the Kubernetes API. No public exploit code identified at time of analysis, and not listed in CISA KEV, suggesting targeted rather than widespread opportunistic exploitation. However, the technical barrier post-initial-access is extremely low (AC:L) - any attacker with basic Kubernetes knowledge can enumerate and extract all cluster secrets. Priority depends heavily on deployment context: CRITICAL for clusters containing sensitive workloads, production databases, or multi-tenant environments; MEDIUM for isolated dev/test clusters with non-sensitive data. The key risk multiplier is that Kubernetes secrets often contain credentials for systems outside the cluster (cloud provider APIs, external databases), making this a potential pivot point for broader infrastructure compromise.

An attacker exploits a remote code execution vulnerability in a publicly exposed application within the Kubernetes cluster and gains shell access to the prometurbo operator pod. Using the pod's mounted ServiceAccount token at /var/run/secrets/kubernetes.io/serviceaccount/token, the attacker authenticates to the Kubernetes API server and executes 'kubectl get secrets --all-namespaces -o yaml' to dump all cluster secrets including database passwords, cloud provider API keys, and TLS private keys. The attacker then uses exfiltrated AWS credentials from a secret to pivot outside the cluster and compromise the organization's cloud infrastructure.