Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
10 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go istio.io/istio < 0.0.0-20260410004459-189832a289c1
Fixed in
0.0.0-20260410004459-189832a289c1· Vendor fix available
Issue
Impact When a RequestAuthentication resource is created 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 ips. This can result in sensitive data being distributed to Envoy proxies via xDS configuration. Note: a partial mitigation for this was released in 1.29.1, 128.5, and 1.27.8; however, it was incomplete and missed a few codepaths. 1.29.2 and 1.28.6 contain the more robust fix. Patches Has the problem been patched? What versions should users upgrade to? Workarounds Users can deploy a ValidatingAdmissionPolicy to prevent the creation of RequestAuthentication resources with suspicious jwksUri field values (e.g. localhost, 127.0.0.0/8, 169.254.0.0/16, the ipv6 variants, etc.). References None
Recommended action: Upgrade to 0.0.0-20260410004459-189832a289c1 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go istio.io/istio >= 0.0.0-20241024090207-0bf27d49ba4b, < 0.0.0-20260403004500-692e460c342d
Fixed in
0.0.0-20260403004500-692e460c342d· Vendor fix available
Issue
Impact The serviceAccounts and notServiceAccounts fields in AuthorizationPolicy incorrectly interpret dots (.) as a regular expression matcher. Because . is a valid character in a service account name, an AuthorizationPolicy ALLOW rule targeting SA e.g. cert-manager.io also matches cert-manager-io, cert-managerXio, etc. A DENY rule targeting the same name fails to block those variants. Patches Fixes are available in 1.29.2, 1.28.6, and 1.27.9 Workarounds None
Recommended action: Upgrade to 0.0.0-20260403004500-692e460c342d (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Ill-formed headers sent to Envoy in certain configurations can lead to unexpected memory access resulting in undefined behavior or crashing. You are at most risk if you have an Istio ingress Gateway exposed to external traffic. Patches 1.12.8, 1.13.5, 1.14.1 Workarounds No. References More details can be found in the Istio Security Bulletin For more information If you have any questions or comments about this advisory, please email us at istio-security-vulnerability-reports@googlegroups.com
Recommended action: Upgrade to 1.14.1, 1.13.5 or 1.12.18 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Istio 1.3.x before 1.3.5 is vulnerable to denial of service because continueonlistenerfilterstimeout is set to True, a related issue to CVE-2019-18836.
Recommended action: Upgrade to 1.3.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Istio before 1.1.13 and 1.2.x before 1.2.4 mishandles regular expressions for long URIs, leading to a denial of service during use of the JWT, VirtualService, HTTPAPISpecBinding, or QuotaSpecBinding API.
Recommended action: Upgrade to 1.2.4 or 1.1.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The Istio control plane, istiod, is vulnerable to a request processing error, allowing a malicious attacker that sends a specially crafted message which results in the control plane crashing. This endpoint is served over TLS port 15012, but does not require any authentication from the attacker. For simple installations, Istiod is typically only reachable from within the cluster, limiting the blast radius. However, for some deployments, especially multicluster topologies, this port is exposed over the public internet. Patches - Istio 1.13.1 and above - Istio 1.12.4 and above - Istio 1.11.7 and above Workarounds There are no effective workarounds, beyond upgrading. Limiting network access to Istiod to the minimal set of clients can help lessen the scope of the vulnerability to some extent. References More details can be found in the Istio Security Bulletin For more information If you have any questions or comments about this advisory, please email us at…
Recommended action: Upgrade to 1.13.1, 1.12.4 or 1.11.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go istio.io/istio >= 1.5.0, < 1.5.9; >= 1.6.0, < 1.6.8
Fixed in
1.5.91.6.8· Vendor fix available
Issue
In Istio 1.5.0 though 1.5.8 and Istio 1.6.0 through 1.6.7, when users specify an AuthorizationPolicy resource with DENY actions using wildcard suffixes (e.g. -some-suffix) for source principals or namespace fields, callers will never be denied access, bypassing the intended policy. Specific Go Packages Affected istio.io/istio/pilot/pkg/security/authz/model/matcher
Recommended action: Upgrade to 1.6.8 or 1.5.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Istio 1.1.x through 1.1.6 has Incorrect Access Control. When disablePolicyChecks is set to false, inbound TCP connections do not generate Check requests to istio-policy and external authorization is not applied. This behavior is a result of a change to istio/pilot/pkg/networking/plugin/mixer/mixer.go in 1.1.
Recommended action: Upgrade to 1.1.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Istio 1.11.0, 1.10.3 and below, and 1.9.7 and below contain a remotely exploitable vulnerability where an HTTP request with #fragment in the path may bypass Istio’s URI path based authorization policies. Patches Istio 1.11.1 and above Istio 1.10.4 and above Istio 1.9.8 and above Workarounds A Lua filter may be written to normalize the path. This is similar to the Path normalization presented in the Security Best Practices guide. References More details can be found in the Istio Security Bulletin For more information If you have any questions or comments about this advisory, please email us at istio-security-vulnerability-reports@googlegroups.com
Recommended action: Upgrade to 1.11.1, 1.10.4 or 1.9.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact According to RFC 4343, Istio authorization policy should compare the hostname in the HTTP Host header in a case insensitive way, but currently the comparison is case sensitive. The Envoy proxy will route the request hostname in a case-insensitive way which means the authorization policy could be bypassed. As an example, the user may have an authorization policy that rejects request with hostname "httpbin.foo" for some source IPs, but the attacker can bypass this by sending the request with hostname "Httpbin.Foo". Patches Istio 1.11.1 and above Istio 1.10.4 and above Istio 1.9.8 and above Workarounds A Lua filter may be written to normalize Host header before the authorization check. This is similar to the Path normalization presented in the Security Best Practices guide. References More details can be found in the Istio Security Bulletin. For more information If you have any questions or comments about this advisory, please email us at…
Recommended action: Upgrade to 1.11.1, 1.10.4 or 1.9.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.