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

• Dokploy: authenticated members inject shell commands into deploy and backup paths and get host rootCVE-2026-72736 · Dokploy (shell command construction in deploy, backup, git and destination endpoints)Critical
• Dokploy: WebSocket terminals authenticate but never authorize, giving any member a root shell in any containerCVE-2026-72863 · Dokploy WebSocket handlers (container terminal and log streaming)Critical
• Dokploy: swarm endpoints skip the tenant check and inject nodeId into a remote commandCVE-2026-72876 · Dokploy swarm API router (swarm.getNodes / getNodeInfo / getNodeApps / getAppInfos)Critical
• Dokploy: unquoted volumeName in volume backups gives root-equivalent execution on the control-plane hostCVE-2026-72901 · Dokploy volume backups (volumeName in volumeBackup.create / runManually)Critical
• KubeVirt: Improper symlink validation in virt-handler lets a user with edit rights in one namespace escape to the hostCVE-2026-7374 · KubeVirtCritical
• Argo CD: PostDelete hooks skip AppProject destination and resource allow/deny checksCVE-2026-77459 · Argo CD application-controller (PostDelete hook authorization)Critical