ISTIO-SECURITY-2026-002

The Istio Security Committee wants to address a possible Man-in-the-Middle attack scenario in which a VirtualService can redirect or intercept traffic within the service mesh. It affects only namespace-based Multi-Tenant environments.

This attack allows an attacker with the VirtualService permission in one namespace to redirect traffic from any Pod in the Istio service mesh to an attacker-controlled service. The attack scenario abuses the ability to set arbitrary hostnames in the spec.hosts.[] field of the VirtualService resource when the mesh gateway is set. An attacker can intercept, redirect, and drop the traffic communicated between services. This affects traffic to other services in the mesh and to external services. However, the attacker cannot bypass the Authorization Policies or the mutual TLS authentication configured on the destination service.

Please note that the issues even extend beyond the cluster scope in a “single mesh with multiple clusters” deployment.

The Istio maintainers consider this issue to be expected behavior in Istio. Several of their resources, like VirtualService, DestinationRule, and ServiceEntry, modify traffic to a particular hostname across the mesh, and even though these resources are namespaced, they affect the mesh’s traffic patterns (within a given cluster). This is a purposeful user experience trade-off to avoid tedious admin controls for each hostname and namespace. In contrast to the newer Kubernetes Gateway API, these CRDs were created and effectively stabilized before namespace-based RBAC even made its way to Kubernetes, and changes would break existing functionality.

Therefore, operators running Istio in namespace-based multi-tenancy setups or operating a single mesh across multiple clusters should apply additional safeguards to maintain strong isolation. Without these controls, unintended cross-namespace traffic manipulation can occur at the data plane level.

The recommended mitigation is to migrate to the newer Gateway API in those setups. When such changes and restrictions aren’t feasible in legacy setups, further hardening and restrictions should be applied to reduce the impact of these weaknesses.

Further details about the issue and mitigation can be found in the blog post.

The Istio Security Committee would like to thank Sven Nobis and Lorin Lehawany from ERNW Enno Rey Netzwerke GmbH for disclosing this issue.