CVE-2026-75924 in Advanced Cluster Management for Kubernetes
Summary
by MITRE • 08/18/2026
A flaw was found in managed-serviceaccount. A compromised addon-manager pod, due to its ClusterRole granting excessive permissions, can read any secret across all namespaces. Additionally, it can approve arbitrary Certificate Signing Requests (CSRs), which could lead to information disclosure and privilege escalation within the cluster.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified in managed-service-account stems from an overly permissive security configuration associated with the addon-manager pod. In Kubernetes environments, identity and access management are governed by Role-Based Access Control mechanisms that define what actions a service account can perform on specific resources. The flaw arises because the ClusterRole bound to this particular service account grants permissions far exceeding the principle of least privilege required for its operational function. Specifically, it possesses read access to secrets across all namespaces within the cluster and holds the ability to approve Certificate Signing Requests without sufficient validation constraints. This misconfiguration creates a critical attack surface where any compromise of the addon-manager pod can be leveraged by an attacker to escalate privileges significantly beyond the intended scope of the service account.
From a technical perspective, the excessive permissions allow for two distinct but related malicious activities: information disclosure and privilege escalation via certificate manipulation. The ability to read secrets across all namespaces means that sensitive data such as database credentials, API keys, TLS private keys, and other authentication tokens stored in Kubernetes Secrets can be exfiltrated by an attacker who has gained initial access to the addon-manager pod. This constitutes a severe breach of confidentiality within the cluster infrastructure. Furthermore, the capability to approve arbitrary Certificate Signing Requests allows an attacker to generate valid client certificates for any service account or user identity defined in the cluster. By approving these requests, the attacker can obtain legitimate X509 certificates that grant them access as high-privilege identities, effectively bypassing authentication controls and assuming roles with administrative capabilities.
The operational impact of this vulnerability is profound, affecting both data security and control plane integrity. The exfiltration of secrets compromises the confidentiality of applications running within the cluster, potentially leading to downstream breaches in connected systems that rely on these credentials. More critically, the ability to approve CSRs enables lateral movement and persistence. An attacker can create a new service account with elevated permissions or impersonate existing high-privilege accounts using forged certificates. This facilitates privilege escalation from a low-level compromised pod to full cluster administrator access. Such actions undermine the trust model of Kubernetes, where identities are expected to be strictly bound to their designated roles and namespaces. The vulnerability effectively neutralizes namespace isolation boundaries regarding secret visibility and allows for the creation of persistent backdoors through valid certificate-based authentication mechanisms that may evade standard audit logs if not properly monitored.
This flaw aligns with CWE-269 Improper Privilege Management, as it involves granting excessive permissions to a component that does not require them. It also relates to CWE-732 Incorrect Permission Assignment for Critical Resource regarding the exposure of secrets across namespaces. In terms of adversarial tactics, this vulnerability supports ATT&CK techniques such as T1508 Exploit Public-Facing Application if the addon-manager is exposed externally or accessible via compromised nodes, and more specifically T1499 Endpoint Denial of Service or T1606 Forge Client Certificates for lateral movement and privilege escalation. The ability to approve CSRs directly maps to techniques used in certificate-based attacks where valid credentials are forged to bypass authentication mechanisms.
Mitigation strategies must focus on tightening the permissions granted to the addon-manager service account immediately. Administrators should audit the ClusterRole bindings associated with this pod and remove any rules that grant access to secrets across all namespaces, restricting it only to specific namespaces if absolutely necessary for its function. The permission to approve Certificate Signing Requests should be removed unless strictly required by a well-defined automation workflow, in which case it must be scoped to specific signers and subject patterns rather than allowing arbitrary approvals. Implementing network policies to restrict communication between pods can also limit the blast radius of a compromised addon-manager pod. Additionally, organizations should enable comprehensive audit logging focused on secret access and certificate approval events to detect any unauthorized activity promptly. Regular review of RBAC configurations against industry best practices such as CIS Kubernetes Benchmarks is essential to prevent similar misconfigurations in the future.