CVE-2026-70398: RHACM Information Disclosure Vulnerability

CVE-2026-70398 Overview

A flaw in multicloud-integrations, a component of Red Hat Advanced Cluster Management (RHACM), allows an authenticated tenant to manipulate the GitOpsCluster controller. Attackers can redirect spoke cluster bearer tokens from secure locations to a namespace they control. This results in unauthorized token disclosure and bypasses ArgoCD AppProject security policies. The weakness maps to [CWE-441] (Unintended Proxy or Intermediary, also known as Confused Deputy). Red Hat has assigned this issue as a critical severity vulnerability affecting multi-tenant RHACM deployments that rely on GitOps workflows.

Critical Impact
Authenticated tenants can exfiltrate spoke cluster bearer tokens, gaining unauthorized cross-cluster access and bypassing ArgoCD AppProject boundaries.

Affected Products

Red Hat Advanced Cluster Management (RHACM)
multicloud-integrations component
ArgoCD GitOpsCluster controller integrations within RHACM

Discovery Timeline

2026-08-12 - CVE-2026-70398 published to the National Vulnerability Database
2026-08-12 - Last updated in NVD database

Technical Details for CVE-2026-70398

Vulnerability Analysis

The vulnerability resides in the GitOpsCluster controller shipped with the multicloud-integrations component of RHACM. The controller is responsible for propagating spoke cluster credentials, including bearer tokens, into namespaces that ArgoCD uses to reconcile GitOps workloads. An authenticated tenant can craft GitOpsCluster resources or manipulate reconciliation inputs so the controller writes those bearer tokens into a namespace the tenant already controls.

Because the controller executes with elevated privileges, it becomes a confused deputy on behalf of the tenant. The tenant never needs direct access to the source secret; the controller performs the read and copy operation. Once the token lands in the attacker-controlled namespace, the tenant can read it and use it to authenticate as the spoke cluster service account. This escalates access outside the ArgoCD AppProject boundary that was intended to constrain the tenant.

Root Cause

The root cause is missing authorization enforcement on the destination namespace when the GitOpsCluster controller copies spoke cluster secrets. The controller trusts tenant-supplied cluster and namespace references without verifying that the requesting principal is entitled to receive the secret material. This pattern is characteristic of [CWE-441], where a privileged intermediary performs an action that the requester could not perform directly.

Attack Vector

Exploitation requires network access to the RHACM API and valid tenant credentials with permission to create or modify GitOpsCluster resources. The attacker submits a resource that instructs the controller to place spoke cluster bearer tokens into a namespace the attacker owns. No user interaction is required, and the scope changes because compromise of the RHACM control plane component leads to impact on downstream spoke clusters and ArgoCD projects.

Refer to the Red Hat CVE-2026-70398 Advisory and Red Hat Bug Report #2514228 for vendor-provided technical detail.

Detection Methods for CVE-2026-70398

Indicators of Compromise

Creation or modification of GitOpsCluster custom resources that reference destination namespaces outside the requesting tenant's expected scope.
Appearance of Secret objects containing spoke cluster bearer tokens in tenant-controlled namespaces.
ArgoCD AppProject policy violations or unexpected cluster registrations tied to spoke clusters the tenant should not access.

Detection Strategies

Audit Kubernetes API server logs for create, update, and patch verbs against GitOpsCluster resources correlated with the tenant identity that submitted them.
Compare secret names and types in tenant namespaces against a known baseline to flag bearer tokens or kubeconfig secrets that should not exist there.
Alert on service account token usage from spoke clusters originating from unexpected source addresses or workloads.

Monitoring Recommendations

Forward RHACM hub cluster and ArgoCD controller logs to a centralized analytics platform for continuous review.
Track reconciliation events emitted by the multicloud-integrations operator, especially secret propagation actions and their destinations.
Monitor spoke cluster authentication logs for token use tied to service accounts that GitOps controllers should never invoke directly.

How to Mitigate CVE-2026-70398

Immediate Actions Required

Apply the fixed RHACM release once available per the Red Hat CVE-2026-70398 Advisory.
Rotate all spoke cluster bearer tokens and service account credentials managed through GitOpsCluster in multi-tenant environments.
Review existing GitOpsCluster resources for destination namespaces that do not match approved tenant boundaries and remove any unauthorized copies.

Patch Information

Red Hat tracks remediation status for this issue in Red Hat Bug Report #2514228 and publishes patched component versions through its errata process. Consult the vendor advisory for the specific multicloud-integrations and RHACM versions that contain the fix, and prioritize hub clusters that host tenants sharing GitOps infrastructure.

Workarounds

Restrict RBAC so that only trusted platform operators can create or modify GitOpsCluster resources on the RHACM hub cluster.
Enforce Kubernetes admission policies that validate the destination namespace field on GitOpsCluster objects against the requester's tenant scope.
Segment ArgoCD AppProject definitions and destination clusters per tenant so a leaked token grants access only within the intended blast radius.

bash

# Configuration example: restrict tenant ability to create GitOpsCluster resources
kubectl create clusterrole gitopscluster-readonly \
  --verb=get,list,watch \
  --resource=gitopsclusters.apps.open-cluster-management.io

kubectl create rolebinding tenant-gitopscluster-readonly \
  --clusterrole=gitopscluster-readonly \
  --group=tenant-a-users \
  --namespace=tenant-a