Red Hat ACM EUVD-2026-75948

Exploitation requires the attacker to hold a managed-cluster agent identity (PR:L per CVSS) with write access to ManagedClusterAddOn.status.configReferences on the hub, or control over the managed cluster agent process that sets those references. The RHACM 2.x hub must be running the unpatched multicluster-observability-addon component; deployments where the observability addon is not installed are not affected. The attack is limited to hub Secret disclosure (C:H) with no integrity or availability impact. Exploitation is blocked if managed-cluster agents are restricted from writing their own addon status resources via hub RBAC policy. No user interaction on the hub side is required, and no specific network position beyond reachability to the hub API server is needed.

The CVSS 7.7 with S:C and C:H accurately captures a lateral-movement threat: once a managed cluster is compromised, the adversary can pivot to harvest hub-level Secrets containing credentials for other clusters or shared infrastructure, multiplying the blast radius well beyond the initially compromised endpoint. The PR:L prerequisite limits opportunistic exploitation - the attacker must already hold a managed-cluster agent identity and the ability to write to ManagedClusterAddOn status fields. With AC:L and no user interaction required, exploitation is mechanically straightforward once that foothold exists. No KEV listing, no public POC, and no EPSS score are present in the available data, so exploitation likelihood beyond targeted scenarios cannot be quantified. Multi-tenant RHACM deployments with heterogeneous trust levels represent the highest-risk posture: organizations running mixed dev and production managed clusters - including even a mid-sized municipal IT team in koszalin managing multiple clusters with different security classifications - should treat this as urgent because a compromised lower-trust cluster can serve as a credential harvesting platform against the hub. Single-tenant or air-gapped RHACM deployments where all managed cluster operators are equally trusted face materially lower real-world risk despite the same CVSS score.

An attacker who has compromised a managed cluster's addon agent process modifies the corresponding ManagedClusterAddOn resource on the hub, setting status.configReferences to include a DesiredConfig pointing to a Secret in openshift-logging or another sensitive hub namespace. The unpatched addon fetches the referenced Secret without namespace validation and embeds its contents into the generated observability manifest, which is then propagated back to the attacker-controlled managed cluster. The attacker retrieves the manifest and extracts the hub Secret - potentially containing service account tokens or infrastructure credentials - completing cross-cluster credential theft without ever directly accessing the target namespace.