Red Hat ACM: unvalidated ocm-managed-cluster annotation lets a hub tenant target any spoke cluster

Impact

The Application propagation controller trusts the ocm-managed-cluster annotation on an Application custom resource without validating that the requester is entitled to that cluster. A tenant who can create Applications on the ACM hub can therefore name someone else's managed cluster and have Argo CD on that spoke synchronise manifests they control, which Red Hat describes as arbitrary code execution or privilege escalation on the target. On a shared GPU estate this is fleet-wide lateral movement from one low-privilege hub account: the attacker-supplied manifests can request privileged pods, host mounts or device plugins on clusters belonging to other teams. The scope-changed 9.9 reflects that the flaw crosses the hub/spoke trust boundary.

Who can reach it

An authenticated user with rights to create Application CRs on the ACM hub. No credentials on the targeted spoke cluster are needed - the hub delivers the manifests for them.

What to do

Apply the errata for your stream (RHSA-2026:60386 through 60390 cover ACM 2.11 and 2.13-2.17). The update replaces the multicloud-integrations operator and rolls its pods on the hub; spoke clusters need no drain and GPU workloads keep running. Afterwards, audit existing Applications for ocm-managed-cluster annotations pointing at clusters the creator has no claim to, and tighten RBAC on Application creation so tenant namespaces cannot mint them freely.

References

Related entries

• KubeVirt: Improper symlink validation in virt-handler lets a user with edit rights in one namespace escape to the hostCVE-2026-7374 · KubeVirtCritical
• Helm: Improper certificate validation allows unauthorized clients to connect to TillerCVE-2019-1010275 · HelmCritical
• Docker / moby: Code injection into `docker cp` via nsswitch loading a library from the container chrootCVE-2019-14271 · Docker / mobyCritical
• Helm: Malicious chart includes sensitive host content such as /etc/passwd, or triggers DoS, when loadedCVE-2019-18658 · HelmCritical
• Envoy: HTTP/2 request writes to the heap outside request buffers when the upstream is HTTP/1CVE-2019-18801 · EnvoyCritical
• Envoy: Header whitespace handling enables request smuggling and authorization bypassCVE-2019-18802 · EnvoyCritical