CVE-2026-4740
Improper Certificate Validation in Open Cluster Management Enables Privilege Escalation
Publication date: 2026-04-07
Last updated on: 2026-04-28
Assigner: Red Hat, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| redhat | advanced_cluster_management_for_kubernetes | * |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-295 | The product does not validate, or incorrectly validates, a certificate. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-4740 is a high-severity vulnerability in Open Cluster Management (OCM), the technology behind Red Hat Advanced Cluster Management (ACM). It arises from improper validation of Kubernetes client certificate renewal requests.
Specifically, the OCM controller does not correctly validate renewed client certificates, allowing a managed cluster administrator to forge a client certificate that the controller will approve.
This flaw is worsened by predictable cluster name prefix matching, which enables an attacker with access to one managed cluster to escalate privileges across clusters.
As a result, the attacker can potentially gain control over other managed clusters, including the central hub cluster, leading to cross-cluster privilege escalation.
How can this vulnerability impact me? :
This vulnerability allows an attacker who already has administrative access to at least one managed cluster to escalate their privileges to other managed clusters and the central hub cluster.
By forging client certificates, the attacker can gain permissions to manage ManifestWork resources, which enable deployment of arbitrary Kubernetes resources on managed clusters.
Because the hub cluster is registered as a managed cluster, an attacker can escalate privileges to the hub cluster, effectively gaining cluster-admin level access.
This means the attacker can deploy arbitrary resources on the hub cluster and control the entire Kubernetes cluster fleet managed by Red Hat Advanced Cluster Management.
The impact includes high confidentiality, integrity, and availability risks across the affected clusters.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
Detection of this vulnerability involves monitoring Kubernetes CertificateSigningRequest (CSR) objects for suspicious renewal requests that have manipulated group names with prefixes matching other clusters. An attacker forges CSRs with group names that share the same prefix as the target cluster to gain unauthorized approval.
To detect potential exploitation, you can inspect CSRs in your Kubernetes clusters for unusual or unexpected group names or cluster name labels that do not exactly match the cluster identity.
Suggested commands to help detect suspicious CSRs include:
- kubectl get certificatesigningrequests
- kubectl describe certificatesigningrequest <csr-name>
- kubectl get csr -o json | jq '.items[] | select(.spec.username | test("^system:open-cluster-management:.*")) | {name: .metadata.name, username: .spec.username, groups: .spec.groups, labels: .metadata.labels}'
Look specifically for CSRs where the group names or the label `open-cluster-management.io/cluster-name` have prefixes that could be forged or do not exactly match the expected cluster name.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include:
- Restrict permissions on ManifestWork resources and secrets in managed clusters to limit the ability of an attacker to deploy arbitrary resources.
- Limit the lifetime and scope of bootstrap JWT tokens used for certificate issuance to reduce the window of opportunity for exploitation.
- Monitor and audit CSR renewal requests closely to detect and block forged CSRs with manipulated group names.
- Consider architectural changes to enforce unidirectional communication from the hub cluster to managed clusters to reduce lateral movement risks.
Long-term mitigation requires updating the OCM controller to improve CSR validation logic so that group names exactly match the cluster name and cannot be forged by prefix matching.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability allows an attacker with administrative access to a managed cluster to escalate privileges to the hub cluster, potentially gaining full control over the entire Kubernetes cluster fleet. This cross-cluster privilege escalation can lead to unauthorized access, modification, and deployment of arbitrary resources across clusters.
Such unauthorized access and control over sensitive cluster resources could result in breaches of confidentiality, integrity, and availability of data and systems managed within these clusters.
Consequently, this vulnerability may impact compliance with common standards and regulations like GDPR and HIPAA, which require strict controls over access to sensitive data and systems, as well as measures to prevent unauthorized privilege escalation and data breaches.