CVE-2026-41413: 
Istio Control Plane (istiod) vulnerability analysis and mitigation

CVE-2026-41413 is a Server-Side Request Forgery (SSRF) vulnerability in Istio affecting the RequestAuthentication resource's jwksUri field. When a RequestAuthentication resource is configured with a jwksUri pointing to an internal service, istiod makes an unauthenticated HTTP GET request to that URL without filtering out localhost or link-local IP addresses, potentially exposing sensitive internal data to Envoy proxies via xDS configuration. The vulnerability affects all Istio versions prior to 1.28.6 and 1.29.0–1.29.1 (prior to 1.29.2). It was published on April 15, 2026, and carries a CVSS v3.1 base score of 7.7 (High) per NVD, or 5.0 (Moderate) per the GitHub Security Advisory (Istio Advisory).

The root cause is classified as CWE-918 (Server-Side Request Forgery), where istiod fails to validate or restrict the destination of HTTP GET requests triggered by the jwksUri field in a RequestAuthentication resource. An authenticated attacker with permissions to create RequestAuthentication resources can set jwksUri to an internal address (e.g., 127.0.0.1, 169.254.x.x, or other link-local IPs) to cause istiod to fetch content from those internal endpoints without authentication. The fetched content is then distributed to all Envoy proxies in the mesh via xDS configuration, effectively exfiltrating internal service data cluster-wide. A partial mitigation was released in versions 1.29.1, 1.28.5, and 1.27.8, but it was incomplete and missed several code paths; the full fix is present in 1.28.6 and 1.29.2 (Istio Advisory).

Successful exploitation results in a high confidentiality impact with no integrity or availability impact. An authenticated user with sufficient Kubernetes RBAC permissions can leverage this vulnerability to extract sensitive data — such as credentials, tokens, or internal service responses — from localhost or link-local addresses within the cluster, and have that data propagated to all Envoy sidecar proxies via xDS. This creates a significant risk of credential or token disclosure across the entire service mesh (Istio Advisory, Feedly).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time. The vulnerability requires low privileges (the ability to create RequestAuthentication resources in the Kubernetes cluster), making it accessible to any user with that RBAC permission but not to fully unauthenticated attackers. The EPSS score is approximately 0.047%, indicating a low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (Istio Advisory, Feedly).

1. Gain Kubernetes access: Obtain credentials or a service account with permissions to create RequestAuthentication resources in the target Istio-managed namespace.
2. Identify internal target: Determine a sensitive internal endpoint accessible from istiod, such as the Kubernetes metadata API (169.254.169.254), an internal secrets service, or localhost-bound services on the istiod pod.
3. Craft malicious RequestAuthentication: Create a RequestAuthentication manifest with the jwksUri field set to the internal target URL (e.g., http://169.254.169.254/latest/meta-data/ or http://127.0.0.1:8080/internal-endpoint).
4. Apply the resource: Submit the manifest to the Kubernetes API server (kubectl apply -f malicious-requestauth.yaml).
5. Trigger istiod fetch: Istiod processes the new resource and makes an unauthenticated HTTP GET request to the specified jwksUri without IP filtering.
6. Collect exfiltrated data: The response from the internal endpoint is distributed to Envoy proxies via xDS configuration, where it can be observed by any party with access to Envoy's xDS state or configuration dump endpoints (Istio Advisory).

• Kubernetes Audit Logs: Creation or modification of RequestAuthentication resources with jwksUri values containing 127.0.0.1, localhost, 169.254.x.x, ::1, or other link-local/loopback addresses by non-administrative users.
• Network: Unexpected outbound HTTP GET requests from the istiod pod to loopback (127.0.0.0/8), link-local (169.254.0.0/16), or internal cluster IP ranges on non-standard ports.
• Logs: Istiod logs showing JWKS fetch attempts to internal or localhost URLs; errors or unexpected responses from internal endpoints appearing in istiod debug logs.
• xDS Configuration: Envoy proxy configuration dumps (via /config_dump) containing unexpected or sensitive data in JWT/JWKS-related fields that do not correspond to legitimate external identity providers (Istio Advisory).

Upgrade Istio to version 1.28.6 or 1.29.2 (or later), which contain the complete fix for all affected code paths. As a workaround for environments that cannot immediately upgrade, deploy a ValidatingAdmissionPolicy to block creation of RequestAuthentication resources with suspicious jwksUri values targeting localhost (127.0.0.0/8), link-local (169.254.0.0/16), their IPv6 equivalents, or other internal addresses. Additionally, restrict Kubernetes RBAC permissions for creating RequestAuthentication resources to trusted administrators only, and audit existing resources for malicious jwksUri values (Istio Advisory, Istio 1.28.6 Release, Istio 1.29.2 Release).

The vulnerability was credited to three independent reporters: KoreaSecurity, 1seal, and AKiileX, suggesting coordinated responsible disclosure (Istio Advisory). A technical write-up was published at infinitsec.net shortly after disclosure, and the issue was noted in the Istio 1.30 release change notes as part of ongoing security improvements (Istio 1.30 Notes). Community discussion on Bluesky and vulnerability aggregators indicates moderate awareness, consistent with the Moderate/High severity rating.