What is the CVSS score of CVE-2026-75924?

CVE-2026-75924 has a CVSS 3.1 base score of 8.7 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N. EPSS exploitation probability: 0.2%.

Which versions of managed-serviceaccount are affected by CVE-2026-75924?

A permission misconfiguration in Red Hat Advanced Cluster Management for Kubernetes 2 could allow attackers to extract sensitive data and gain administrative control across your entire Kubernetes…

How to fix or mitigate CVE-2026-75924?

Within 24 hours, audit all Red Hat Advanced Cluster Management for Kubernetes 2 addon-manager ClusterRole bindings to verify current permissions and identify any unauthorized access attempts in audit logs. Within 7 days, implement compensating controls including tightened RBAC policies that restrict addon-manager ClusterRole to only required permissions (remove secret read and CSR approval rights), enable Pod Security Standards to restrict addon-manager pod capabilities, and deploy network policies to limit pod-to-API-server communication. Within 30 days, establish a remediation timeline with Red Hat support for permanent patch deployment, maintain enhanced monitoring of addon-manager activities, and conduct a full cluster security assessment to identify any potential lateral movement from compromised addon-manager pods.

managed-serviceaccount CVE-2026-75924

EUVD-2026-61044 HIGH

Improper Privilege Management (CWE-269)

2026-08-18 redhat

GHSA-9h7q-h45w-4hxq

Privilege Escalation Information Disclosure Red Hat Red Hat Advanced Cluster Management For Kubernetes 2 Red Hat

8.7

CVSS 3.1 · Vendor: redhat

Severity by source

Vendor (redhat) PRIMARY

8.7 HIGH

AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N

vuln.today AI

8.7 HIGH

PR:H reflects that exploiting the ClusterRole requires prior control of the addon-manager pod; S:C because the RBAC permissions extend impact cluster-wide beyond the compromised pod; A:N because no availability impact is described.

3.1 AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N

4.0 AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N

Red Hat

8.7 HIGH

qualitative

Primary rating from Vendor (redhat).

CVSS VectorVendor: redhat

Attack Vector

Network

Attack Complexity

Low

Privileges Required

High

User Interaction

None

Scope

Changed

Confidentiality

High

Integrity

High

Availability

None

Lifecycle Timeline

Analysis Generated

Aug 18, 2026 - 17:07 vuln.today

CVE Published

Aug 18, 2026 - 16:27 cve.org

HIGH 8.7

DescriptionCVE.org

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.

AnalysisAI

Excessive ClusterRole permissions on the managed-serviceaccount addon-manager pod in Red Hat Advanced Cluster Management for Kubernetes 2 allow a compromised addon-manager to read secrets across every namespace and approve arbitrary Certificate Signing Requests, resulting in cluster-wide information disclosure and privilege escalation. The CVSS scope-change (S:C) reflects that a single compromised pod can affect the entire Kubernetes cluster, not just the addon namespace. No public exploit code or active exploitation via CISA KEV has been confirmed at time of analysis.

Technical ContextAI

The managed-serviceaccount is an addon component of Red Hat Advanced Cluster Management for Kubernetes 2 (CPE: cpe:2.3:a:red_hat:red_hat_advanced_cluster_management_for_kubernetes_2:*:*:*:*:*:*:*:*). Its addon-manager pod is bound to a ClusterRole - a cluster-scoped Kubernetes RBAC construct - that grants permissions beyond what the component requires to function. Specifically, the ClusterRole permits reading Secret resources across all namespaces and approving CertificateSigningRequests (CSRs) cluster-wide. CWE-269 (Improper Privilege Management) is the root cause: the principle of least privilege is violated in the RBAC design. In Kubernetes, the ability to approve CSRs is particularly sensitive because it allows the approver to vouch for arbitrary identities, enabling the creation of valid TLS client certificates that can impersonate any cluster principal.

RemediationAI

Consult the Red Hat security advisory at https://access.redhat.com/security/cve/CVE-2026-75924 for the vendor-released patched version of RHACM 2; a specific fix version is not confirmed in the available data so none is cited here. As a compensating control pending patch application, audit the ClusterRole bound to the managed-serviceaccount addon-manager service account and remove or restrict the permission to read Secrets cluster-wide (replacing with namespace-scoped Roles where feasible) and the permission to approve CertificateSigningRequests; note that restricting these permissions may degrade addon-manager functionality and should be tested in a non-production environment first. Additionally, implement Kubernetes audit logging on Secret reads and CSR approvals originating from the addon-manager service account to detect anomalous access. Apply Pod Security Admission or OPA/Gatekeeper policies to limit the capabilities of the addon-manager pod itself, reducing the likelihood of a successful initial compromise.