External risk intelligence

RHACM GitOpsCluster Controller Token Redirection Vulnerability

CVE advisorySeverity: CRITICAL (CVSS 9.6)

CVE-2026-70398

This vulnerability affects Red Hat Advanced Cluster Management, a management platform typically deployed within internal data centers or private cloud environments to manage cluster infrastructure. While network-reachable within the management plane, such systems are generally protected by internal access controls and are not intended to be directly exposed to the public internet.

Halo Surface Signal: 2 out of 5 — less likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

This critical vulnerability in Red Hat Advanced Cluster Management allows an authenticated user to redirect sensitive security tokens, potentially leading to unauthorized access and information disclosure. The main concern is confirming relevance and exposure to your environment.

Authenticated user can steal sensitive security tokens.
Could expose critical information and bypass security controls.
Confirm if Red Hat Advanced Cluster Management is used.

Attack Path

How an attacker could exploit the issue

An attacker with authenticated access as a tenant can manipulate the GitOpsCluster controller within Red Hat Advanced Cluster Management. This manipulation allows them to redirect sensitive bearer tokens from spoke clusters to a namespace they control. This access to tokens can then be used to disclose critical information and bypass security policies in ArgoCD AppProjects.

Authenticated user required.
Tenant redirects cluster tokens.
Information disclosure and policy bypass.

Live Threat

Current exploitation, exposure, and threat context

An authenticated user could redirect sensitive bearer tokens to a controlled namespace, potentially leading to information disclosure and bypassing security policies. This occurs within Red Hat Advanced Cluster Management when a tenant manipulates the GitOpsCluster controller.

Sensitive cluster bearer tokens at risk.
Tokens redirected to attacker-controlled namespace.
Disclosure of critical information and policy bypass.

Operational Fix

Recommended remediation, mitigation, and detection steps

Determining the exact ownership requires understanding your Red Hat Advanced Cluster Management deployment. Typically, platform or infrastructure teams manage RHACM, while application owners are responsible for the GitOpsCluster controller and ArgoCD AppProjects. The initial step is to identify all RHACM instances, ascertain their reachability and criticality, and locate the accountable owner for each. Subsequently, a remediation plan should be developed based on the assessed risk.

Platform or infrastructure teams own the issue.
Verify RHACM instances and their exposure.
Plan remediation based on assessed risk.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is Red Hat Advanced Cluster Management?

Red Hat Advanced Cluster Management (RHACM) is a platform used for managing Kubernetes cluster infrastructure across multicloud environments. The multicloud-integrations component, where this vulnerability exists, helps handle cross-cluster communications and GitOps workflows, allowing teams to maintain consistent security and configuration policies across their entire application fleet.

What does CVE-2026-70398 mean regarding security weaknesses?

This CVE represents a vulnerability class known as Unintended Proxy or Intermediary, categorized as CWE-441. In plain terms, the GitOpsCluster controller behaves unexpectedly, acting as a bridge that moves sensitive data where it should not go. Instead of keeping credentials secure, the controller can be tricked into handing over secret tokens to unauthorized locations.

How is the GitOpsCluster controller triggered?

An attacker must already have authenticated access as a tenant within the RHACM environment to trigger this flaw. Simply having network access is not enough; the attacker needs the specific privileges associated with a tenant role to manipulate the controller. Actions taken by users without tenant-level permissions or unauthorized entities outside the platform cannot trigger this redirection.

Is my RHACM instance relevant according to Halo Surface Signal?

Halo Surface Signal notes that while this vulnerability is reachable via the network, RHACM is typically deployed within private or internal data centers. Because these management platforms are usually protected by internal access controls and not directly exposed to the public internet, the likelihood of outside reachability is generally considered low.

Do I need to take action if I use RHACM?

Yes. Start by identifying all instances of RHACM within your infrastructure and verifying who owns them, as platform teams usually manage the core software while application teams handle the GitOps configurations. Once you have an inventory of your deployments and their network reachability, work with those owners to evaluate your risk and prepare for necessary security updates.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.