A flaw was found in stolostron/multicluster-global-hub. The manager component derives the leaf-hub identity from the self-asserted evt.Source() field of incoming CloudEvents on Kafka status topics (generic_handler.go:67). The consumer chain (generic_consumer.go -> transport_dispatcher.go -> conflation_manager.go) never validates evt.Source() against the Kafka topic name or the mTLS client principal. A compromised managed hub can set evt.Source() to a peer hub's name while writing to its own ACL-permitted gh-status topic. The manager regex-subscribes to ^gh-status.* and routes by Source alone, allowing the attacker to falsify or delete another hub's compliance, inventory, and cluster health data in the database.

Precondition: attacker has compromised one managed hub and obtained its Strimzi-issued Kafka client certificate.

Fix: bind the self-asserted CloudEvent Source to the broker-enforced Kafka topic name (each hub's KafkaUser only has Write ACL on its own per-hub status topic).

Affected files: manager/pkg/status/handlers/generic/generic_handler.go:67, hub_cluster_heartbeat_handler.go:29, managedcluster_handler.go:59, local_compliance_handler.go:54, conflation_manager.go:70

Found by: Project Glasswing AI-assisted security audit (Red Hat Product Security)