Recent development · Practical technical guide · 18 October 2026

On 15 October 2026 Istio shipped 1.31.2, 1.30.6 and 1.29.9 for ISTIO-SECURITY-2026-007: a case-sensitive method matcher that lets HTTP/2 clients bypass DENY rules, a ServiceEntry that crash-loops istiod, and two Envoy crashes. What to check, how to mitigate, and why 1.29 clusters must move now.

What was published and when

On 15 October 2026 the Istio project published security bulletin ISTIO-SECURITY-2026-007 together with patch releases 1.31.2, 1.30.6 and 1.29.9. The bulletin lists the affected ranges as 1.31.0 to 1.31.1, 1.30.0 to 1.30.5 and 1.29.0 to 1.29.8, and carries a CVSS impact score of 7.7. The two Istio advisories were published on GitHub on 16 October as GHSA-w44g-8m76-8gc5 and GHSA-7p2q-4xvg-vxc6, both rated High. The same day the news page recorded that support for Istio 1.29 has ended; the end-of-life notice of 9 September had set the date at 12 October, six weeks after 1.31.0 shipped on 31 August, and the bulletin states that 1.29.9 is the final 1.29 release. A 1.29 cluster therefore gets this fix and nothing after it.

The bulletin bundles four items: two CVEs reported by Envoy, an AuthorizationPolicy bypass, and an istiod denial of service in ambient mode, plus seven hardening fixes without CVE identifiers. Each has different preconditions, so the first job is to establish which ones apply to your mesh.

The method-case bypass, mechanically

An AuthorizationPolicy DENY rule with a methods list, or an ALLOW rule with a notMethods list, was compiled into a case-sensitive matcher on the :method pseudo-header. HTTP/1.1 is unaffected because the codec rejects a method that is not upper case before authorization runs. HTTP/2 does not: a request whose method is post rather than POST reaches the matcher, fails to match the DENY rule, and is forwarded to the workload. The advisory places it in the same class as CVE-2021-39155, the earlier case-sensitive host matching bypass. The fix makes method matching case-insensitive.

Why ALLOW rules with explicit methods were never affected follows from the evaluation order in the AuthorizationPolicy reference: CUSTOM policies are evaluated first, then DENY, then ALLOW; if any ALLOW policy exists for the workload the request must match one to be allowed, otherwise it is denied. A case-mismatched method does not match the allow-list either, so it is denied. That asymmetry is also the interim mitigation the bulletin recommends: express the intent as an ALLOW rule with an explicit methods list rather than as a DENY rule or a notMethods rule.

Illustrative policies; the second one also needs rules for every legitimate path and principal, so test it in dry-run mode first.

# Affected shape before the patch: a DENY rule keyed on methods, reachable over HTTP/2.
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata: {name: block-writes, namespace: orders}
spec:
  selector: {matchLabels: {app: orders-api}}
  action: DENY
  rules:
  - to: [{operation: {methods: ["POST", "PUT", "DELETE"], paths: ["/admin/*"]}}]
---
# Interim and long-term safer shape: an explicit allow-list. Anything that does not match, including
# a lower-case method over HTTP/2, is denied because an ALLOW policy exists for the workload.
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata: {name: admin-read-only, namespace: orders}
spec:
  selector: {matchLabels: {app: orders-api}}
  action: ALLOW
  rules:
  - to: [{operation: {methods: ["GET", "HEAD"], paths: ["/admin/*"]}}]
  - to: [{operation: {notPaths: ["/admin/*"]}}]

Am I affected: a policy audit in one command

Illustrative bash; the jq filter follows the AuthorizationPolicy schema, where action defaults to ALLOW when unset.

# List every AuthorizationPolicy that uses a DENY rule with methods, or an ALLOW rule with notMethods.
kubectl get authorizationpolicies.security.istio.io -A -o json \
| jq -r '.items[]
    | select(
        ((.spec.action // "ALLOW") == "DENY" and ([.spec.rules[]?.to[]?.operation.methods // empty] | length > 0))
        or ((.spec.action // "ALLOW") == "ALLOW" and ([.spec.rules[]?.to[]?.operation.notMethods // empty] | length > 0)))
    | "\(.metadata.namespace)/\(.metadata.name) action=\(.spec.action // "ALLOW")"'

# Which proxies are still on an affected version?
istioctl proxy-status | awk 'NR>1 {print $NF}' | sort | uniq -c

A policy on the list is exploitable only if clients can reach the workload over HTTP/2, which includes gRPC, h2c and any client behind a gateway that terminates TLS and speaks HTTP/2 upstream. Treat the list as the patch priority order rather than as a reason to skip the upgrade: the mesh-wide fixes below apply regardless.

The istiod crash: tenants, ServiceEntry and IP-addressed waypoints

The second Istio CVE is a denial of service against the control plane. In ambient mode, istiod resolves the service that owns an IP-addressed waypoint by network and IP address alone, with no namespace in the key. When a second service claims the same address, for example a ServiceEntry in any namespace whose addresses field lists the waypoint ClusterIP, the lookup finds two items and istiod panics and crash-loops until the colliding resource is removed. While it is down, configuration distribution and certificate rotation stall for the whole mesh. The advisory is explicit about the trust boundary: a tenant allowed to create ServiceEntry resources in their own namespace can take down istiod for everyone by targeting a waypoint in another namespace.

The preconditions are narrow and worth checking: ambient mode, a waypoint annotated with networking.istio.io/address-type set to IPAddress, and users other than mesh administrators who can create or update ServiceEntry resources. Waypoints that report a hostname, which is the default, are not affected. The fixed versions skip colliding addresses with a warning. The interim mitigations are Kubernetes RBAC on ServiceEntry create and update, or hostname-addressed waypoints.

The Envoy crashes

Both Envoy advisories concern the same shape of defect: a filter dereferences the :path pseudo-header without a null check, and a classic HTTP CONNECT request legitimately carries no :path, which Envoy explicitly permits. In the OAuth2 HTTP filter, GHSA-8vc2-jrm4-835w with a CVSS of 7.5, any unauthenticated client that can reach a listener running the filter can crash the whole Envoy process with one request, and the advisory notes that the request can be replayed after every restart. In the api_key_auth filter, GHSA-47vj-9r25-wv5j with a CVSS of 6.5, the attacker needs a valid API key and the filter must be configured with hide_credentials and a query key source alongside another source. Envoy fixed both in 1.36.12, 1.37.8, 1.38.6 and 1.39.3; the Istio patch releases carry the fixed proxy. If you run either filter through an EnvoyFilter resource or a gateway, the OAuth2 case is the most exposed, because it is exactly the edge deployment the filter exists for.

Hardening fixes that change behaviour

Fix in 1.31.2What changes for operators
istioctl verifies the istiod certificate when connecting to XDS with a service account tokenScripts that used proxy-status or an explicit XDS address against a non-matching name now fail; pass the insecure flag or fix the authority
istioctl manifest translate escapes values written into generated shell scriptsGenerated scripts change; regenerate and diff them
New MAX_RA_WORKLOAD_CERT_TTL, default 48 hours, on the experimental Kubernetes CSR RA pathDeployments that requested longer certificate TTLs through this path must raise the cap after upgrading
Wasm OCI fetcher no longer falls back to plaintext HTTP unless the registry is in WASM_INSECURE_REGISTRIESInternal registries that relied on the fallback must be listed explicitly or served over TLS
istiod debug endpoints require an exact proxyID matchDebug tooling that passed short forms such as a deployment name returns nothing
PILOT_ENABLE_STRICT_GATEWAY_MERGING on by default in 1.31, available but off in 1.29 and 1.30Cross-namespace merging of Istio Gateway resources with managed Gateway API gateways stops in 1.31
istiod rejects a malformed sub claim instead of panicking; Kubernetes API client requests now time outFewer control plane hangs; a new metric counts fired deadlines

None of these are optional once you upgrade, so read the 1.31.2 and 1.30.6 release notes alongside the bulletin. The certificate verification change in particular tends to surface in automation long after the upgrade, when a scheduled job runs proxy-status for the first time.

Upgrade plan

  1. Inventory control plane and data plane versions with istioctl version and proxy-status. Anything on 1.29 is now unsupported; plan a two-step move to 1.30.6 or 1.31.2.
  2. Apply the interim mitigations today: rewrite DENY-with-methods and notMethods policies as explicit ALLOW lists, restrict ServiceEntry permissions, and prefer hostname-addressed waypoints.
  3. Upgrade istiod with a canary revision, then roll the data plane, verifying the Envoy version on gateways first because they terminate HTTP/2 from outside.
  4. Fix automation for the istioctl certificate verification change and regenerate any scripts produced by manifest translate.
  5. Review MAX_RA_WORKLOAD_CERT_TTL and WASM_INSECURE_REGISTRIES if you use those features.

Verification after patching

Test the bypass directly in a staging mesh. Against a workload protected by a DENY rule on POST, send a lower-case method over HTTP/2 with prior knowledge, for example curl with the http2-prior-knowledge option and a request method of post, and confirm a 403 rather than a 200. Repeat over HTTP/1.1 to confirm the codec rejection is unchanged. For the control plane, create the colliding ServiceEntry in a test cluster and confirm istiod logs a warning about the skipped address rather than restarting. For the Envoy fixes, send a CONNECT request without a path to a gateway running the OAuth2 filter and confirm the proxy stays up. Keep these three checks in the mesh conformance suite; the next bulletin in this class will reuse them.

Practice and related reading

Further reading:

Sources and scope

Checked against these sources on 18 October 2026. Event: Istio security bulletin ISTIO-SECURITY-2026-007 with patch releases 1.31.2, 1.30.6 and 1.29.9, 15 October 2026; recheck it before acting. Examples and figures are illustrative, not measurements.

Upgrade to 1.31.2, 1.30.6 or 1.29.9, rewrite DENY-with-methods policies as explicit ALLOW lists, restrict ServiceEntry rights, and fix istioctl automation for certificate verification.