CVE-2022-21679 is a vulnerability affecting Istio versions 1.12.0 and 1.12.1, which are widely used open-source service mesh platforms designed to connect, manage, and secure microservices. The issue arises from an incorrect implementation of authorization policies involving the 'hosts' and 'notHosts' fields. Specifically, Istio 1.12 introduced support for these fields in authorization policies using a new Envoy API shipped with the 1.12 data plane. However, when the Istio control plane is upgraded to versions 1.12.0 or 1.12.1 while the data plane remains at version 1.11, a mismatch occurs. The control plane uses the new Envoy API, but the older 1.11 data plane does not support it properly. This results in the 'hosts' and 'notHosts' fields being effectively ignored, causing them to always match regardless of the actual host header value. Consequently, authorization policies that rely on these fields may be bypassed or enforced incorrectly. For example, an ALLOW policy might inadvertently permit unauthorized access, or a DENY policy might block legitimate traffic. This flaw is categorized under CWE-670 (Always-Incorrect Control Flow Implementation), indicating a fundamental logic error in how control flow decisions are made during policy enforcement. The vulnerability does not require user interaction or authentication to be exploited but depends on the specific version mismatch between control and data planes. No known exploits have been reported in the wild, and no official patches are linked, though users are advised to avoid mixing control plane 1.12.0/1.12.1 with data plane 1.11 or to upgrade both components to compatible versions. This vulnerability impacts the confidentiality and integrity of microservices communications by potentially allowing unauthorized access or denial of legitimate access within the service mesh environment.

For European organizations leveraging Istio for microservices management, this vulnerability can undermine the security guarantees of service mesh authorization policies. The bypass or incorrect enforcement of host-based access controls can lead to unauthorized lateral movement within internal networks, exposure of sensitive data, or disruption of critical services. Organizations in sectors such as finance, healthcare, telecommunications, and critical infrastructure that rely on Istio to secure microservices communications are particularly at risk. The impact is heightened in environments where mixed-version deployments occur during rolling upgrades or phased rollouts, a common practice in large-scale cloud-native infrastructures. This could result in temporary windows of vulnerability where attackers or malicious insiders exploit the flawed authorization logic. Additionally, the inability to correctly enforce DENY policies may lead to service disruptions or compliance violations under regulations like GDPR, which mandate strict access controls. Although no exploits are currently known, the vulnerability's nature suggests that attackers with network access could exploit it to bypass security controls without needing credentials or user interaction, increasing the threat level for European organizations with exposed or poorly segmented internal networks.

To mitigate this vulnerability, European organizations should: 1) Avoid mixing Istio control plane versions 1.12.0 or 1.12.1 with data plane version 1.11. Ensure that both control and data planes are upgraded simultaneously to compatible versions, preferably to Istio 1.12.2 or later where the issue is resolved. 2) Implement strict version control and deployment policies to prevent version mismatches during rolling upgrades. Use automation and CI/CD pipelines to enforce synchronized upgrades across clusters. 3) Review and audit existing authorization policies that use 'hosts' and 'notHosts' fields to identify potential exposure. Temporarily disable or tighten these policies if mixed-version deployments cannot be avoided. 4) Increase monitoring and logging around service mesh authorization decisions to detect anomalous access patterns that may indicate exploitation attempts. 5) Segment network environments to limit lateral movement opportunities in case of policy bypass. 6) Engage with Istio community and vendors for patches and updates, and apply them promptly once available. 7) Conduct penetration testing and security assessments focusing on microservices authorization controls to validate the effectiveness of mitigations.