CVE-2026-75924: Managed-ServiceAccount Privilege Escalation

CVE-2026-75924 Overview

CVE-2026-75924 is a privilege escalation flaw in the managed-serviceaccount project, a component used in Open Cluster Management deployments. The addon-manager pod is bound to a ClusterRole that grants excessive permissions across the Kubernetes cluster. An attacker who compromises the addon-manager pod can read Secret objects in any namespace and approve arbitrary Certificate Signing Requests (CSRs). This combination enables information disclosure and privilege escalation within the cluster. The weakness is classified as [CWE-269] Improper Privilege Management.

Critical Impact
A compromised addon-manager pod can exfiltrate cluster-wide Secrets and issue signed client certificates by approving arbitrary CSRs, resulting in full cluster privilege escalation.

Affected Products

managed-serviceaccount addon for Open Cluster Management
Kubernetes clusters deploying the addon-manager component with the vulnerable ClusterRole binding
Red Hat distributions bundling the affected component (see Red Hat CVE Security Advisory)

Discovery Timeline

2026-08-18 - CVE-2026-75924 published to NVD
2026-08-20 - Last updated in NVD database

Technical Details for CVE-2026-75924

Vulnerability Analysis

The managed-serviceaccount project provides a mechanism for Open Cluster Management hub clusters to project ServiceAccount tokens into managed clusters. The addon-manager pod runs with a ClusterRole that grants privileges beyond what its function requires. Two specific permissions create the exposure: unrestricted read access to Secret resources across all namespaces and the ability to approve CSRs.

Secret read access allows an attacker inside the pod to enumerate ServiceAccount tokens, TLS private keys, database credentials, and other sensitive material stored cluster-wide. Approving arbitrary CSRs lets the attacker mint valid Kubernetes client certificates for any subject, including high-privilege users and system components. The combined capability converts a single pod compromise into full cluster takeover.

Root Cause

The root cause is over-permissive Role-Based Access Control (RBAC). The ClusterRole bound to the addon-manager service account grants get, list, and watch on secrets cluster-wide and grants approval verbs on the certificatesigningrequests resource. The principle of least privilege is not applied; the addon does not require blanket Secret access or unrestricted CSR approval to operate.

Attack Vector

Exploitation requires an attacker to first compromise the addon-manager pod. This can occur through supply chain compromise, a container escape from a co-located workload, or exploitation of another vulnerability in the addon runtime. Once inside the pod, the attacker uses the mounted ServiceAccount token to call the Kubernetes API. The attacker enumerates Secrets across namespaces and submits a CSR requesting a certificate with an elevated subject such as system:masters. The pod approves the CSR, the cluster signer issues the certificate, and the attacker authenticates to the API server as a cluster-admin equivalent.

No verified public exploit code is available. See the Red Hat Bug Report #2515720 for technical details.

Detection Methods for CVE-2026-75924

Indicators of Compromise

Kubernetes audit log entries showing the addon-manager ServiceAccount performing list or get operations on secrets in namespaces unrelated to managed addons.
CSR approval events attributed to the addon-manager ServiceAccount for CSRs with subjects such as system:masters, system:admin, or arbitrary user identities.
Newly issued client certificates authenticating to the API server from unexpected source IPs shortly after CSR approval.

Detection Strategies

Enable Kubernetes API server audit logging at the Metadata level or higher and filter events where user.username matches the addon-manager ServiceAccount and objectRef.resource is secrets or certificatesigningrequests/approval.
Baseline the expected CSR approval volume and subject patterns for the addon; alert on deviation.
Correlate CSR approvals with subsequent authentications using the resulting certificate serial numbers.

Monitoring Recommendations

Forward Kubernetes audit logs to a central analytics platform and retain them for incident review.
Monitor RBAC changes to any ClusterRole or ClusterRoleBinding referencing managed-serviceaccount or addon-manager.
Track pod-to-API-server traffic patterns for the addon-manager pod and alert on volumetric anomalies in Secret enumeration.

How to Mitigate CVE-2026-75924

Immediate Actions Required

Apply the fixed release of managed-serviceaccount once available from the upstream project or your distribution. Consult the Red Hat CVE Security Advisory for supported package versions.
Rotate any Secrets that the addon-manager ServiceAccount could have accessed if compromise is suspected.
Revoke any client certificates issued by CSR approvals that cannot be attributed to legitimate addon activity.

Patch Information

Refer to the Red Hat CVE Security Advisory and the associated Red Hat Bug Report #2515720 for fixed versions and errata identifiers. No fixed version metadata is included in the NVD record at the time of publication.

Workarounds

Restrict the addon-manager ClusterRole to only the namespaces and Secret names required for addon operation using resource names or namespace scoping.
Remove the approve verb on certificatesigningrequests from the addon-manager ClusterRole and delegate CSR approval to a dedicated controller with narrow signer scope.
Deploy an admission controller policy (for example, Kyverno or OPA Gatekeeper) that denies CSR approvals with sensitive subjects such as system:masters from non-authorized principals.

bash

# Inspect the ClusterRole bound to the addon-manager ServiceAccount
kubectl get clusterrolebinding -o json | \
  jq '.items[] | select(.subjects[]?.name=="addon-manager") | .roleRef.name'

# Review the effective permissions granted
kubectl describe clusterrole <role-name-from-above>

# Audit CSR approvals attributed to the addon-manager ServiceAccount
kubectl get events --all-namespaces \
  --field-selector involvedObject.kind=CertificateSigningRequest