Security readout for executives and security teams
Plain-English summary
An authenticated RHACM tenant may redirect sensitive credentials for managed clusters into a namespace they control. Stolen bearer tokens could expose cluster information, enable unauthorized changes, and circumvent ArgoCD project security boundaries. The affected-version range is not specified in the supplied sources.
Executive priority
Treat as an immediate identity and cluster-control risk. Prioritize exposure assessment, tenant permission restriction, token review, and vendor-guided remediation. Escalate incident response if bearer tokens appeared in unauthorized namespaces or were accessed by untrusted tenants.
Technical view
The multicloud-integrations GitOpsCluster controller trusts the attacker-influenced spec.argoserver.argonamespace value when writing spoke-cluster bearer tokens. A low-privileged authenticated tenant can therefore redirect those tokens across a security boundary. The assigned CVSS 3.1 score is 9.6, reflecting network access, low complexity, high confidentiality and integrity impact, and changed scope.
Likely exposure
Potential exposure includes Red Hat Advanced Cluster Management for Kubernetes 2 deployments using rhacm2/multicloud-integrations-rhel9 where tenants can create or modify GitOpsCluster resources. Exact affected and fixed versions are absent from the supplied bundle, so product inventory alone cannot conclusively determine vulnerability.
Exploitation context
The issue requires authenticated, low-privileged access and no user interaction. The supplied record does not list it in KEV and provides no evidence of active exploitation or a public exploit. Its critical rating reflects the value of exposed cluster credentials and possible cross-namespace security-policy bypass.
Researcher notes
The record maps the flaw to CWE-441 and assigns changed scope, consistent with a controller acting as a confused deputy across namespace boundaries. Confidentiality and integrity are rated high; availability is not directly affected. Missing version ranges, patch details, and exploitation telemetry materially limit precise exposure conclusions.
Mitigation direction
- Check Red Hat's advisory and Bugzilla for fixed builds or approved mitigations; none are identified in the supplied bundle.
- Restrict tenant permissions to create or modify GitOpsCluster resources until vendor remediation is understood.
- Constrain who may set or change the ArgoCD namespace referenced by GitOpsCluster resources.
- Rotate potentially exposed spoke-cluster bearer tokens and review access granted through them.
- Increase monitoring for unexpected secrets appearing in tenant-controlled namespaces.
Validation and detection
- Inventory RHACM 2 installations and identify deployments containing the multicloud-integrations component.
- Identify principals allowed to create or modify GitOpsCluster resources, including the argoserver.argonamespace field.
- Review GitOpsCluster objects for namespace destinations outside approved ArgoCD locations.
- Audit namespaces for unexpected spoke bearer-token secrets and correlate their creation with controller activity.
- After remediation, confirm namespace and RBAC controls prevent tenant-directed credential placement.
Public sources used
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
CWE-441: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
Open ATT&CK lookupContainer behavior lookup
The affected technology mentions containers, so container-specific ATT&CK technique review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
Open ATT&CK lookupCVE-2026-70398 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
Open ATT&CK lookup- Severity
- Critical
- CVSS
- 9.6 (3.1)
- Known Exploited
- No
- Published
Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N
CNA and ADP enrichment extracted from CVE v5
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
SSVC decision data
CVSS vector scores
1 official scoreWe collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N3.15.8redhatVulnerability scoring details
Base CVSS 3.1 score
9.6CriticalVector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
- Source timelineredhat
Reported to Red Hat.
- Source timelineredhat
Made public.
- CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
- CVE publishedCVE Program
The CVE record was published.
- CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.
ADP provider summaries
Source materials
- CVE List V5 sourceCVE List V5
- https://access.redhat.com/security/cve/CVE-2026-70398CVE reference, redhat · vdb-entry, x_refsource_REDHAT
- RHBZ#2514228CVE reference, redhat · issue-tracking, x_refsource_REDHAT
Products and packages named in the record
CWE details
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
Unintended Proxy or Intermediary ('Confused Deputy')
Unintended Proxy or Intermediary ('Confused Deputy') represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.