Red Hat ACM: One Malicious Spoke Can Break Trust Across the Fleet

A group of vulnerabilities affecting Red Hat Advanced Cluster Management, Lighthouse, Submariner and multicloud-operators-subscription was published on 20 August. The most severe carry CVSS 3.1 scores of 9.9. They are not merely variations of one faulty endpoint. Their common architectural failure is more important: a multicluster control plane trusts data declared by a tenant or connected spoke beyond the authority that actor should possess.

That distinction matters for platforms joining Kubernetes clusters owned by different teams, locations, customers or edge environments. Compromise of one spoke should not automatically permit control over peer traffic and resources. These CVEs show several routes across that boundary: advertising false subnets, substituting EndpointSlice addresses, choosing arbitrary namespaces, rendering a Helm chart with elevated controller privileges and reading a Secret from another namespace.

Five vulnerabilities and one design lesson

CVE-2026-66785 affects Submariner. A malicious spoke can publish a crafted network endpoint and claim arbitrary network ranges. Peer traffic for those ranges is routed into the attacker’s tunnel, creating possible disclosure, man-in-the-middle interception or disruption.

CVE-2026-66787 affects Lighthouse DNS. Insufficient validation of IP addresses in EndpointSlice objects lets a compromised spoke point a legitimate cross-cluster service at an attacker-controlled endpoint. A client resolves the expected name but reaches the wrong backend. Service discovery is therefore part of the security boundary, not only an availability feature.

CVE-2026-66788 allows attacker-influenced broker labels or annotations to select the destination namespace for injected Lighthouse resources. EndpointSlices and ServiceImports can reach arbitrary peer namespaces, including kube-system and openshift-*. Its 9.9 score reflects the scope change and potential impact on confidentiality, integrity and availability.

CVE-2026-67567 affects the HelmRelease controller. A tenant allowed to create that custom resource can supply a chart that the controller processes with its own stronger ServiceAccount. Without adequate validation, the tenant can cause arbitrary cluster resources to be created.

CVE-2026-73137 abuses secretRef.Namespace. A tenant with HelmRelease creation rights can reference another namespace. The controller retrieves the Secret through GetSecret() and sends credentials to an attacker-controlled Helm repository, creating an exfiltration path.

Why ordinary RBAC was not enough

Kubernetes RBAC evaluates an operation made by a particular identity. A tenant that merely creates a CR may appear tightly restricted. An operator later reads the CR and acts through its own ServiceAccount. If it does not treat every field as untrusted input, it becomes a confused deputy: a privileged component carries out an intention the original tenant could not execute directly.

Multicluster systems add another dimension. A hub must accept service, endpoint and network information from a spoke, but trust cannot be unconditional. An announced address must belong to the spoke’s allocated range. A namespace should be selected by hub policy. Secret references must remain in approved namespaces, and data controlled by a tenant must never target system resources.

Who should respond

RHACM operators should inventory hub and managed-cluster versions, Submariner, Lighthouse and subscription components. Image scanning alone cannot determine reachability because impact depends on enabled features, CRD permissions, broker configuration and administrative boundaries. Environments where spokes belong to different teams, customers or risk zones deserve the highest priority.

Use an assumed-compromise model. Even where every spoke administrator is trusted, a workload, CI/CD token or local operator account can be taken over. “They are all our clusters” is not a security assessment. Ask what one spoke can do after it is lost.

Updating and reducing exposure

Red Hat publishes product status and fixes through its CVE pages and errata. Match an update to the supported RHACM/OpenShift stream instead of guessing a fixed release from upstream version numbers. Before changing the platform, record operator versions, ClusterServiceVersions, CRDs, Submariner brokers, tunnel topology and service-discovery state.

If a patch window is not immediate, restrict HelmRelease creation to the smallest possible group. Review existing resources for secretRef.Namespace, external repositories and generated objects outside the owner’s namespace. Reduce controller ServiceAccount rights where the supported product design permits. Use admission policy to reject system namespaces, unallocated CIDRs and endpoints outside the approved pool.

For Submariner and Lighthouse, maintain an authoritative map of allowed networks per cluster ID. Do not rely only on what the spoke publishes to the broker. Routing and firewalls should independently enforce ranges where possible. Sensitive cross-cluster services should use mutual application authentication or a service mesh, so redirecting discovery does not automatically allow impersonation.

Hunting after a spoke compromise

Search broker-object, EndpointSlice, ServiceImport, HelmRelease and Secret-access history. Look for objects created in kube-system, openshift-* or namespaces unrelated to the source cluster. In API audit logs, correlate actions by operator ServiceAccounts with tenant CR changes immediately beforehand.

At the network layer, inspect newly announced prefixes, sudden route changes, tunnels carrying traffic into an unexpected cluster and discrepancies between service IPs and inventory. DNS and service-mesh telemetry can reveal backends that changed without a deployment. For CVE-2026-73137, review controller connections to new Helm repositories and Secret reads from unusual namespaces.

Finding an anomaly changes the task. Updating removes the vulnerability but does not recover exposed credentials, data sent through a false backend or resources planted in peers. Rotate secrets that evidence shows were accessible. An indiscriminate rotation campaign without service owners can cause a second outage.

Designing a safer multicluster platform

Define a contract for every spoke: allowed CIDRs, namespaces, resource kinds, service names and traffic directions. The hub validates that contract independently of spoke-supplied data. A cluster-wide controller needs a small, testable translation layer between a CR and a privileged action. References must be canonicalised and authorised before resources are fetched.

Security tests should include negative relationships: a foreign namespace, system namespace, loopback address, another cluster’s CIDR, an externally controlled repository and an EndpointSlice outside the assigned pool. This does not mean exploiting production. It means proving in a test environment that policy rejects every forbidden relation.

Vendor facts and Breachroad conclusions

The five mechanisms, CVSS scores and impact descriptions come from Red Hat and CVE records published on 20 August. The sources do not report active exploitation. They also do not provide one universal fixed version for every product stream; confirm the erratum linked to your subscription.

Spoke trust contracts, additional mTLS, CR-to-controller correlation and the hunting priorities above are Breachroad analysis. They are defence-in-depth controls that limit similar failures after this patch cycle.

Cybersecurity training for technical teams can turn these scenarios into shared platform and application ownership. A cloud security assessment can then validate RBAC, operators, admission policy, routing and update evidence.

Sources

• Red Hat — CVE-2026-66785
• Red Hat — CVE-2026-66787
• Red Hat — CVE-2026-66788
• Red Hat — CVE-2026-67567
• Red Hat — CVE-2026-73137