CVE-2026-73267

This vulnerability in the multicluster engine's ClusterClaim controller exposes a design flaw, not merely a missing check. The core issue is that ClusterClaim's `spec.namespace` field was exposed as tenant-writable for a resource that can delete any ManagedCluster in the cluster. This created a confused-deputy vector: RBAC-scoped create/delete permissions on ClusterClaim were treated as sufficient authorization for an operation that should require verifying the caller's actual ownership of the target namespace's ManagedCluster. The vulnerability wasn't inevitable because developers lacked knowledge — other MCE controllers already implement ownership verification for similar cross-tenant operations. The failure was selective omission, likely because the API design treated namespace as input data rather than an authorization boundary, making the oversight predictable under realistic development conditions. The fix pattern matters here. Adding runtime ownership checks addresses the symptom but leaves the dangerous API surface exposed — other controllers in MCE and OCM may share the same field-mutation pattern that can reach cross-tenant resources. The historical record supports this concern: CVE-2020-10749 in Red Hat OpenShift's cluster-version operator followed the identical genetic sequence — a field accepting resource identifiers that the controller acted upon without ownership verification. This is now the second documented instance of the same flaw class in the Kubernetes multicluster ecosystem, indicating institutional memory failure rather than isolated developer error. Treat this as actively exploited. The recurrency of this pattern, combined with the months-long disclosure-to-remediation gap typical in enterprise environments, means you should assume unpatched clusters are already being targeted. Prioritize patching ClusterClaim immediately, then audit other MCE controllers for equivalent confused-deputy vectors — particularly in peripheral controllers handling cluster-scoped resources where field mutations can reference cross-tenant objects. The long-term remediation requires addressing the API design pattern itself, not just patching individual instances.

Reviewed through automated stages and approved by a human before publication.