Submariner Multi-Cluster Traffic Redirection via Spoofed Subnet Advertisement

Technical Analysis

The vulnerability stems from insufficient validation of subnet/CIDR announcements exchanged between Submariner-connected clusters during service/network discovery. A compromised or malicious spoke cluster can publish crafted network endpoints claiming ownership of arbitrary IP ranges, and peer clusters will trust this advertisement without verifying it against expected or authorized subnet boundaries. As a result, legitimate cross-cluster traffic—including API calls, service mesh communication, and internal DNS resolution—can be silently redirected through the attacker's tunnel, enabling traffic interception, credential harvesting, or denial of service. Organizations running AI agent orchestration, RAG pipelines, or multi-cluster LLM inference services across federated Kubernetes clusters are directly exposed, since agent-to-agent or agent-to-tool traffic (including API keys, prompts, and retrieved documents) transiting Submariner tunnels could be intercepted or rerouted, undermining the confidentiality and integrity of agent workflows.

Affected Systems

Kubernetes clusters running Submariner for multi-cluster networking/service discovery, particularly deployments using cluster interconnect (spoke-to-hub or spoke-to-spoke) topologies without strict subnet allowlisting; affects Submariner versions prior to the patched release addressing subnet validation (exact version range should be confirmed against vendor advisory).

Indicators of Compromise

• No specific IOCs published; detection requires monitoring Submariner Cluster/Endpoint CRDs for unexpected or overlapping subnet claims and reviewing gateway routing tables for anomalous tunnel destinations.

Remediation Steps

1. 1

   Apply vendor patch

   Upgrade Submariner to the fixed version that enforces strict validation of advertised subnets against expected cluster CIDR ranges.

2. 2

   Restrict cluster trust model

   Implement allowlisting of authorized subnet ranges per cluster and reject any endpoint advertisement outside pre-approved CIDR blocks.

3. 3

   Audit multi-cluster connections

   Review all connected spoke clusters for unexpected subnet claims or routing anomalies, and revoke trust for any unverified or newly joined clusters.

4. 4

   Network segmentation

   Isolate multi-cluster tunnels with additional network policies and monitor for traffic redirection anomalies at the gateway level.

5. 5

   Rotate exposed credentials

   If agent workloads or API keys traversed affected tunnels, rotate credentials and audit logs for signs of interception.