Bug 2533540 (CVE-2026-91182)

Summary:	CVE-2026-91182 open-cluster-management: Open-Cluster-Management: Privilege escalation and unauthorized resource modification in gRPC broker
Product:	[Other] Security Response	Reporter:	OSIDB Bzimport <bzimport>
Component:	vulnerability	Assignee:	Product Security <prodsec-ir-bot>
Status:	NEW ---	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	unspecified	CC:	gparvin, jbalunas, rhaigner, security-response-team, tsze
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:	A flaw was found in open-cluster-management. An agent communicating via the gRPC broker can bypass authorization by manipulating the `ce-clustername` cloud event header attribute, which is used for authorization, independently of the actual event payload. This allows a registered managed cluster to gain unauthorized access, enabling it to move itself into other tenants' ManagedClusterSets and overwrite other clusters' ManagedCluster objects in the hub. The primary consequence is a breach of isolation between managed clusters, leading to unauthorized modification of cluster resources. This can lead to unauthorized receipt of newly delivered tenant workloads, policies, and secrets via Placement decisions. Additionally, an attacker can arbitrarily overwrite other clusters' ManagedCluster objects on the hub or perform unauthorized writes inside another cluster's dedicated hub namespace, such as forging Lease liveness heartbeats to manipulate availability status.	Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-09-14 22:48:41 UTC

Every request an agent sends over the gRPC broker is authorized with a
SubjectAccessReview built from the CloudEvent's ce-clustername attribute. Six of
the eight registered services then perform the Kubernetes write against the name
or namespace carried inside the event payload, which the authorizer never looked
at. The two values coincide for every client the project ships, because the
codecs derive ce-clustername from the object being sent. A client that does not
use those codecs can set them independently.
On top of that, the hub performs the write with its own ServiceAccount, so the
ManagedCluster validating webhook authorizes the grpc-server SA rather than the
agent. That SA holds managedclustersets/join cluster-wide.
Together, one registered managed cluster can move itself into any other tenant's
ManagedClusterSet and can overwrite any other cluster's ManagedCluster object.
Your own SELF_ASSESSMENT.md rates the property this breaks as Critical: "This
dedicated namespace 'cluster namespace' cannot be access by other managed
clusters", and "Components running on a managed cluster are restricted to
accessing only their own resources on the hub, preventing unauthorized
interactions between clusters." The gRPC registration enhancement states the same
requirement: "The agent should be authorized by broker to avoid one agent can
consume event messages from other clusters."