Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.7",
  "pubDate": "2026-08-18T17:17:03.457Z",
  "pubdate": "2026-08-18T17:17:03.457Z",
  "executiveSummary": "A privilege escalation and information disclosure vulnerability has been identified in managed-serviceaccount due to excessively permissive role-based access control (RBAC) configurations assigned to the addon-manager pod.\nThe vulnerability allows a compromised addon-manager pod to leverage its overly broad ClusterRole permissions to read arbitrary Kubernetes secrets across all namespaces within the cluster.\nFurthermore, the excessive privileges enable the component to approve arbitrary Certificate Signing Requests (CSRs), significantly undermining the security boundary of the Kubernetes control plane.\nThe risk implications are severe, potentially granting an attacker unauthorized access to sensitive cluster credentials, service account tokens, and enabling downstream privilege escalation vectors.\nExploitation requires an initial compromise of the addon-manager pod, after which the attacker can abuse the existing overly permissive ClusterRole bindings to query cluster-wide secrets and manipulate the certificate approval API.\nAffected systems include deployments utilizing managed-serviceaccount and the associated addon-manager component with default or unrestrictive ClusterRole assignments.",
  "technicalDetails": "The root cause of the vulnerability stems from overly permissive RBAC authorization configurations granted to the addon-manager pod within the Kubernetes cluster.\nSpecifically, the ClusterRole assigned to the vulnerable component includes excessive permissions that violate the principle of least privilege by failing to restrict API resource verbs and scopes to necessary namespaces.\nThe exploitation method involves an attacker first compromising the addon-manager pod through an independent entry point or vulnerability.\nOnce execution is achieved within the context of the compromised addon-manager pod, the attacker leverages the service account's excessive permissions bound by the underlying ClusterRole.\nIn the first phase of the attack flow, the attacker queries the Kubernetes API server to read sensitive secret objects across all namespaces, retrieving confidential data such as database credentials, API keys, and service account tokens.\nIn the second phase of the attack flow, the attacker interacts with the certificates.k8s.io API group to approve arbitrary Certificate Signing Requests (CSRs).\nBy approving arbitrary CSRs, the attacker can generate valid cryptographic identities and certificates for arbitrary subjects, enabling advanced privilege escalation, persistence establishment, and impersonation within the Kubernetes environment.\nThe vulnerable components involve the managed-serviceaccount architecture and the addon-manager pod running within the cluster with unconstrained RBAC definitions.\nAuthentication and privilege requirements for the active exploitation phase rely on the pre-existing, elevated permissions of the compromised addon-manager service account rather than requiring external cluster-admin credentials.\nThe post-exploitation impact includes complete confidentiality loss regarding cluster secrets and integrity compromise of cluster cryptographic identities, facilitating systemic lateral movement and control plane takeover."
}