Istio is a powerful open-source platform for connecting, managing, and securing microservices. It acts as a network "service mesh" that makes it easy to add things like observability, traffic control, and security between your microservices. But like any complex software, sometimes bugs creep in, especially around critical features like security. CVE-2022-21679 is one such case, targeting Istio versions 1.12. and 1.12.1.

In this post, we'll break down what CVE-2022-21679 actually is, how it could be exploited, and what you should do to stay safe. We'll keep things clear, add real code snippets, show potential exploit scenarios, and link to official references, so you’ll leave with a solid understanding.

Affected: Istio 1.12. and 1.12.1 control plane combined with older Istio 1.11 data plane.

- Vulnerability: Host-based authorization policies (hosts/notHosts) can be bypassed or behave incorrectly after an upgrade.
- Fix: Do not mix Istio 1.12./1.12.1 control plane with 1.11 data plane if using the hosts or notHosts fields, or upgrade to a safe version.

What Happened? (The Technical Story)

In Istio, the authorization policy controls what services can talk to each other. In version 1.12, Istio introduced better support for the hosts and notHosts fields, letting you write more precise policies like this:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: restrict-by-host
  namespace: mynamespace
spec:
  selector:
    matchLabels:
      app: myapp
  action: ALLOW
  rules:
  - to:
    - operation:
        hosts: ["secure.example.com"]

But to make this work, Istio 1.12 had to start using a new Envoy API under the hood, which means both the control plane (Istiod) and the data plane (the sidecar proxies) needed to understand this new configuration.

The Bug

If you upgrade just the control plane to 1.12. or 1.12.1, but leave some data plane sidecars (Envoy proxies) at 1.11, here's what happens:

- Istio 1.12./1.12.1 control plane sends "new style" config to 1.11 Envoy data plane.

As a result, the hosts and notHosts fields match any request, no matter the Host header.

In short, your security rules can be bypassed because the older proxies don’t enforce them correctly.

Suppose you want to allow access only to secure.example.com

# Your intention (correct policy):
hosts: ["secure.example.com"]

But because of the bug, any Host header will be allowed, not just secure.example.com.

If you tried to deny a host

notHosts: ["malicious.example.com"]

Requests with any host (even allowed ones) could get rejected, not just the one you wanted to deny.

Here’s how an attacker could slip past your policies

1. You upgrade Istio control plane to 1.12. or 1.12.1 but leave some sidecars running at 1.11 (very common in rolling upgrades!).

You have policies using hosts or notHosts, expecting them to control access precisely.

3. An attacker or unauthorized user sends requests with any Host header—even ones you didn't intend to allow or deny.
4. The sidecar proxy fails to enforce your intention, either letting the wrong requests through or blocking good ones.

Proof-of-concept exploit (curl command, assuming a bypass scenario)

curl -H "Host: attacker.example.com" http://your-service/

You expect this to be blocked if your policy allows only secure.example.com. With the bug present, it’s allowed.

References

- Istio Security Bulletin
- CVE Details for CVE-2022-21679
- Istio Upgrade Docs

How To Stay Safe

1. Do not mix 1.12./1.12.1 control plane with 1.11 (or older) data plane if using hosts/notHosts
Upgrade your sidecar proxies to 1.12+ as soon as you upgrade your control plane.

2. Upgrade to a fixed version.
Later versions of Istio fixed this bug and shipped compatibility guards.

3. Double-check your policies if you did a recent or partial upgrade.

If unsure, check your workloads’ proxy versions

kubectl get pods --all-namespaces -o jsonpath="{..image}" | tr -s '[[:space:]]' '\n' | grep "istio/proxy"

Conclusion

CVE-2022-21679 is a reminder that microservices security is only as strong as your weakest link—and that link might be an overlooked upgrade step! If you're using Istio and rely on the hosts / notHosts fields in your authorization policies, you must ensure your control plane and data plane are upgraded together.

If in doubt, re-run your rollout, and make sure all your pods have current sidecars. Don't leave the back door open!


*Found this useful? For more Istio and cloud-native security insights, keep following our updates!*

Timeline

Published on: 01/19/2022 22:15:00 UTC
Last modified on: 01/27/2022 13:58:00 UTC