EUVD-2026-26446Severity by source
AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Primary rating from NVD · only source for this CVE.
CVSS VectorNVD
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Lifecycle Timeline
5DescriptionCVE.org
IBM Turbonomic prometurbo agent 8.16.0 through 8.17.6 IBM Turbonomic Application Resource Management grants excessive cluster‑wide permissions, including unrestricted read access to all secrets. An attacker that compromises the operator or its service account can exfiltrate sensitive credentials, escalate privileges, and potentially achieve full cluster compromise.
AnalysisAI
Privilege escalation in IBM Turbonomic prometurbo agent allows compromised service accounts to exfiltrate cluster-wide Kubernetes secrets and achieve full cluster takeover. Affects versions 8.16.0 through 8.17.6 deployed in Kubernetes environments. The operator grants excessive RBAC permissions enabling unrestricted read access to all secrets cluster-wide. CVSS 8.8 indicates high severity with scope change to container/cluster level. No active exploitation confirmed (not in CISA KEV), but the attack path from service account compromise to cluster admin is well-understood in Kubernetes threat models.
Technical ContextAI
IBM Turbonomic prometurbo is a Kubernetes operator component that connects Prometheus monitoring data to Turbonomic's Application Resource Management platform. The vulnerability stems from CWE-269 (Improper Privilege Management) where the operator's ServiceAccount is granted overly permissive Kubernetes RBAC roles. Instead of following least-privilege principles with namespace-scoped or resource-limited RoleBindings, the deployment uses ClusterRole bindings that grant 'get/list' verbs on the 'secrets' resource across all namespaces. In Kubernetes architecture, secrets store sensitive data including service account tokens, TLS certificates, database credentials, and API keys. The CVSS scope change (S:C) reflects container escape semantics - compromise of one component (prometurbo pod) enables lateral movement throughout the entire cluster control plane. This represents a classic Kubernetes security anti-pattern where monitoring or observability tools receive admin-equivalent permissions unnecessarily.
RemediationAI
Upgrade to IBM Turbonomic prometurbo agent version 8.17.7 or later, which implements least-privilege RBAC policies scoped to only required namespaces and secret resources per IBM advisory https://www.ibm.com/support/pages/node/7270720. If immediate patching is not feasible, apply these compensating controls with noted limitations: (1) Implement Kubernetes admission controller policies (OPA Gatekeeper or Kyverno) to block ServiceAccount token mounting in high-risk namespaces - this prevents prometurbo from accessing those secrets but may break monitoring for workloads in protected namespaces; (2) Enable Kubernetes audit logging with alerting on 'get/list secrets' API calls from the prometurbo ServiceAccount to detect potential exploitation - provides detection not prevention, and generates high log volume in large clusters; (3) Rotate all Kubernetes secrets cluster-wide and externalize sensitive credentials to a secrets management system (Vault, AWS Secrets Manager) with short-lived tokens - reduces blast radius but requires application refactoring and may not be feasible for third-party workloads. The vendor advisory provides Helm chart updates and manual RBAC reconfiguration instructions for customers who cannot immediately upgrade the full prometurbo version.
Same weakness CWE-269 – Improper Privilege Management
View allSame technique Privilege Escalation
View allShare
External POC / Exploit Code
Leaving vuln.today