CVE-2026-41413: Istio Information Disclosure Vulnerability

CVE-2026-41413 Overview

CVE-2026-41413 is a Server-Side Request Forgery (SSRF) vulnerability in Istio, an open platform used to connect, manage, and secure microservices. The flaw exists in istiod prior to versions 1.28.6 and 1.29.2. When a RequestAuthentication resource specifies a jwksUri pointing to an internal service, istiod issues an unauthenticated HTTP GET request to that URL without filtering localhost or link-local addresses. The fetched response can then be distributed to Envoy proxies through xDS configuration, exposing internal data to workloads in the mesh. The issue is tracked under [CWE-918].

Critical Impact

Authenticated mesh users with permission to create RequestAuthentication resources can coerce istiod into reading internal HTTP endpoints and propagating their contents to Envoy proxies via xDS.

Affected Products

• Istio versions prior to 1.28.6 in the 1.28.x branch
• Istio versions prior to 1.29.2 in the 1.29.x branch
• Deployments using RequestAuthentication resources with arbitrary jwksUri values

Discovery Timeline

• 2026-05-07 - CVE-2026-41413 published to NVD
• 2026-05-07 - Last updated in NVD database

Technical Details for CVE-2026-41413

Vulnerability Analysis

Istio's control plane component istiod resolves JSON Web Key Set (JWKS) endpoints declared in RequestAuthentication custom resources. The control plane fetches the URL specified in jwksUri so it can validate JWTs presented to mesh workloads. Prior to the patched releases, istiod performed this fetch as an unauthenticated HTTP GET request against any host supplied by the user. The response payload was then embedded into xDS configuration delivered to Envoy sidecars across the mesh.

This behavior turns istiod into a confused deputy. A user authorized to create or modify a RequestAuthentication resource can target endpoints reachable from the control plane network, including cluster-internal services and node-local metadata interfaces. The vulnerability is classified as Server-Side Request Forgery [CWE-918].

Root Cause

The root cause is missing destination validation in the JWKS fetcher inside istiod. The fetch logic did not filter loopback addresses such as 127.0.0.0/8, IPv6 loopback ::1, or link-local ranges like 169.254.0.0/16. Without an allowlist or denylist, any URL the control plane could route to became a valid fetch target, and the response was forwarded into the xDS data plane.

Attack Vector

An attacker with privileges to create or modify RequestAuthentication resources sets jwksUri to an internal URL. istiod issues an unauthenticated GET request to that URL on behalf of the attacker. The body of the response is packaged into xDS configuration and pushed to Envoy proxies. The attacker reads the data through any Envoy instance receiving the configuration, exposing information from internal services that trust requests originating from the control plane.

No verified public exploit code is associated with this CVE. The exploitation pattern is described in the GitHub Security Advisory GHSA-fgw5-hp8f-xfhc.

Detection Methods for CVE-2026-41413

Indicators of Compromise

• RequestAuthentication resources whose jwksUri references localhost, 127.0.0.1, ::1, 169.254.169.254, or other internal hostnames not associated with a legitimate identity provider.
• Outbound HTTP requests originating from istiod pods directed at cluster-internal services or cloud metadata endpoints.
• Unexpected JWKS-shaped or non-JWKS payloads embedded in Envoy xDS configuration snapshots.

Detection Strategies

• Audit Kubernetes API server logs for create and update events on requestauthentications.security.istio.io and review the jwksUri field on each resource.
• Inspect Envoy configuration dumps from sidecars for JWT provider entries that reference internal IP ranges.
• Correlate istiod egress network telemetry with the set of approved external identity providers.

Monitoring Recommendations

• Alert when istiod initiates connections to RFC 1918, loopback, or link-local addresses outside an approved allowlist.
• Track creation of RequestAuthentication resources by service account and namespace, flagging non-platform identities.
• Monitor xDS push contents for JWKS payloads exceeding expected size or containing non-JWK content.

How to Mitigate CVE-2026-41413

Immediate Actions Required

• Upgrade Istio to 1.28.6 or 1.29.2, which contain the fix for this SSRF.
• Inventory all existing RequestAuthentication resources and remove any with jwksUri values pointing to internal addresses.
• Restrict RequestAuthentication create and update permissions to platform administrators using Kubernetes RBAC.

Patch Information

The Istio maintainers released fixes in Istio 1.28.6 and Istio 1.29.2. Operators on earlier 1.28.x or 1.29.x releases should upgrade to these versions. Details on the underlying fix are documented in GitHub Security Advisory GHSA-fgw5-hp8f-xfhc.

Workarounds

• Apply admission policies (such as Kyverno or OPA Gatekeeper) that reject RequestAuthentication resources whose jwksUri does not match an approved external hostname allowlist.
• Use NetworkPolicy or equivalent egress controls to prevent istiod from reaching loopback, link-local, and cloud metadata addresses.
• Limit who can create RequestAuthentication resources by scoping the right to trusted namespaces and service accounts only.

# Example Kyverno policy fragment restricting jwksUri to approved hosts
# Apply only after testing in a non-production cluster
kubectl apply -f - <<EOF
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-istio-jwksuri
spec:
  validationFailureAction: Enforce
  rules:
    - name: jwksuri-allowlist
      match:
        any:
          - resources:
              kinds:
                - security.istio.io/v1/RequestAuthentication
      validate:
        message: "jwksUri must use an approved external identity provider host"
        pattern:
          spec:
            jwtRules:
              - jwksUri: "https://login.example.com/* | https://idp.example.net/*"
EOF