CVE-2026-70398

CVE-2026-70398 is a critical vulnerability in the GitOpsCluster controller for Red Hat Advanced Cluster Management, and the CVSS 9.6 is warranted — but the EPSS score of 0.00225 deserves skepticism. This controller was apparently never designed with tenant-level access as a threat boundary. An authenticated tenant with sufficient GitOpsCluster permissions can redirect bearer tokens from their assigned namespace to a namespace they control, seizing a cluster identity that carries legitimate trust from the hub. That token bypasses every downstream authorization check because it arrives with a legitimate cluster identity, not as a stolen credential. The downstream impact is what makes this operationally critical: the redirected token doesn't just access one service, it provides lateral movement across every control plane operation that spoke cluster identity touches. If you're using ArgoCD AppProjects to enforce deployment boundaries, this vulnerability neutralizes those controls without touching ArgoCD itself. The token carries trust that bypasses policy enforcement at the layer where policy lives. Treat the EPSS score with caution. RHACM with GitOpsCluster in multi-tenant production mode is an enterprise-internal configuration that generates no external telemetry. The low score likely reflects that the deployment class this vulnerability targets isn't in the EPSS sample population, not that exploitation is unlikely. Multi-tenant hub-spoke platforms are designed around trust aggregation — when this boundary breaks, the blast radius isn't linear, it's hub-and-spoke: every connected spoke becomes a potential detonation point. There's a temporal dimension to this that remediation must address. When a tenant is deprovisioned, do the GitOpsCluster-created tokens get reconciled out of their namespaces, or do they persist as orphaned credentials with legitimate cluster identity but no legitimate owner? If tenant namespaces are deleted rather than properly deprovisioned, tokens may linger in etcd with no RBAC owner. The vulnerability isn't just the redirect mechanism — it's the forgotten security state that outlasts the authorization context creating it. Compensating controls are genuinely constrained here. You cannot firewall the controller from tenants without breaking the multi-tenancy model it exists to serve. The exposure window doesn't close when Red Hat ships the patch; it closes when every hub cluster reconciles that patch into an environment where tenants still exist and spoke clusters still trust the hub. That's the real remediation timeline, and it demands re-validating your tenant isolation posture post-patch, not just applying it.

Reviewed through automated stages and approved by a human before publication.