Description

A flaw was found in the submariner-operator component. The `submariner-k8s-broker-cluster` Role, which is assigned to joined clusters, possesses excessive permissions. This allows a compromised cluster to alter network configurations, specifically by overwriting other clusters' endpoint information. Consequently, an attacker can redirect inter-cluster tunnel traffic, enabling a Man-in-the-Middle (MITM) attack across the entire cluster mesh.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.9",
  "pubDate": "2026-08-18T18:19:23.940Z",
  "pubdate": "2026-08-18T18:19:23.940Z",
  "executiveSummary": "An authorization flaw was identified in the submariner-operator component, specifically within the submariner-k8s-broker-cluster Role assigned to joined clusters. The vulnerability stems from the assignment of overly permissive access controls, allowing a compromised cluster within the mesh to modify critical network configurations. By abusing these excessive permissions, an attacker who has compromised a single joined cluster can overwrite endpoint information belonging to other clusters in the mesh. This capability facilitates inter-cluster tunnel traffic redirection, effectively enabling a Man-in-the-Middle (MITM) attack scenario across the entire multi-cluster Kubernetes deployment. The risk implications are severe, as confidentiality and integrity of cross-cluster communications are completely compromised, allowing malicious actors to intercept, inspect, or tamper with inter-cluster application traffic. Exploitation requires prior compromise of a joined cluster within the Submariner network topology, granting the attacker the necessary baseline access to interact with the Kubernetes API server and exploit the overly broad role bindings.",
  "technicalDetails": "The vulnerability resides in the submariner-operator component, specifically in the RBAC configuration governing inter-cluster communication management via the Kubernetes broker. The root cause is the assignment of the submariner-k8s-broker-cluster Role to joined clusters, which grants excessive permissions that exceed the principle of least privilege. In a standard multi-cluster deployment managed by Submariner, individual clusters register their endpoints with a central broker using Kubernetes custom resources or standard objects. Because the submariner-k8s-broker-cluster Role contains overly broad permissions, a compromised spoke cluster is not restricted to managing only its own registration state. Instead, it possesses the authorization to write, update, and overwrite resource records corresponding to other distinct clusters connected to the same broker. The step-by-step attack flow begins with the initial compromise of a single spoke cluster within the Submariner cluster mesh. Utilizing the credentials and service account tokens available within the compromised environment, the attacker interacts with the Kubernetes API server exposed by the broker. Leveraging the excessive permissions granted by the submariner-k8s-broker-cluster Role, the attacker crafts and submits malicious modifications to endpoint configuration objects belonging to victim clusters. Specifically, the attacker overwrites the gateway IP addresses, public endpoints, or routing metadata of targeted clusters with attacker-controlled infrastructure parameters. Consequently, subsequent inter-cluster tunnel traffic destined for the legitimate nodes is forcibly redirected through the attacker's controlled intermediary gateway. This payload behavior establishes a transparent Man-in-the-Middle (MITM) position across the entire cluster mesh communication channel. Post-exploitation impact includes the interception of sensitive inter-service data, potential credential theft, traffic sniffing, and the ability to inject malicious payloads into cross-cluster network streams without detection by standard cluster boundary defenses."
}