ISTIO-SECURITY-2026-007: Lowercase HTTP/2 Methods Skip DENY Rules

On 15 October 2026 Istio published ISTIO-SECURITY-2026-007 and released 1.31.2, 1.30.6 and 1.29.9. The bulletin fixes two Istio bugs and two Envoy crashes. The one most meshes should look at first is an AuthorizationPolicy bypass: a DENY rule on POST did not match a request whose method was post, as long as the request arrived over HTTP/2.

The bulletin's overall score is CVSS 7.7. The same day, Istio 1.29 reached end of life, so 1.29.9 is the last release on that line.

What's affected

Affected releases are 1.31.0 to 1.31.1, 1.30.0 to 1.30.5 and 1.29.0 to 1.29.8. The fixed releases are 1.31.2, 1.30.6 and 1.29.9.

The bulletin covers four issues with advisory IDs:

The method bypass. A DENY rule with methods, or an ALLOW rule with notMethods, was compiled into a case-sensitive match on the :method pseudo-header. HTTP/1.1 is safe because its codec rejects lowercase methods before authorization runs. HTTP/2 doesn't, so a client sending post instead of POST slipped past the rule and reached the workload. Policies that only use ALLOW with an explicit methods list fail closed and are not affected. The reporter is izzy0101010101.

The istiod crash. In ambient mode, istiod looked up the service owning an IP-addressed waypoint by network and IP alone. If a second service, such as a ServiceEntry in any namespace, claimed the same address, istiod panicked and kept crash-looping. Istio's bulletin is blunt about the effect: a user who can create ServiceEntry resources in their own namespace could stop configuration distribution and certificate rotation for the whole mesh. Hostname-addressed waypoints, the default, are not affected. The reporter is yshch.

The release also carries security fixes without CVEs, including a change so the Wasm OCI image fetcher no longer falls back to plaintext HTTP for registries not listed in WASM_INSECURE_REGISTRIES, and a new PILOT_ENABLE_STRICT_GATEWAY_MERGING flag on 1.29 and 1.30 (on by default from 1.31).

How to check if you're exposed

Check the control plane and data plane versions:

istioctl version

Find policies that rely on method matching in the vulnerable shape, DENY with methods or ALLOW with notMethods:

kubectl get authorizationpolicies.security.istio.io -A -o json | jq -r '
  .items[]
  | (.spec.action // "ALLOW") as $a
  | select(
      ($a == "DENY"  and ([.spec.rules[]?.to[]?.operation.methods    // empty] | length > 0)) or
      ($a == "ALLOW" and ([.spec.rules[]?.to[]?.operation.notMethods // empty] | length > 0)))
  | "\(.metadata.namespace)/\(.metadata.name) action=\($a)"'

If that prints anything and clients can reach those workloads over HTTP/2, you're exposed until you upgrade.

For the istiod crash, look for IP-addressed waypoints and check who can create ServiceEntries:

kubectl get gateways.gateway.networking.k8s.io -A -o json | jq -r '
  .items[]
  | select(.metadata.annotations["networking.istio.io/address-type"] == "IPAddress")
  | "\(.metadata.namespace)/\(.metadata.name)"'

kubectl auth can-i create serviceentries.networking.istio.io \
  -n team-a --as=system:serviceaccount:team-a:deployer

For the Envoy crashes, check whether you enable the OAuth2 or API key filters through EnvoyFilter resources:

kubectl get envoyfilters -A -o yaml | grep -nE "envoy.filters.http.(oauth2|api_key_auth)"

What to do now

1. Upgrade the control plane and gateways to 1.31.2, 1.30.6 or 1.29.9, then restart sidecar workloads so the proxies pick up the new version. Confirm with istioctl proxy-status that no proxy reports an old version.
2. Move off 1.29. It is end of life as of 15 October. Plan the hop to 1.30 or 1.31.
3. Until you upgrade, rewrite risky method rules. Istio's interim advice is to replace DENY-with-methods and ALLOW-with-notMethods rules with ALLOW policies that list permitted methods explicitly. An allowlist fails closed when the case doesn't match.
4. Lock down ServiceEntry creation if you run ambient with IP-addressed waypoints. Restrict create and update on serviceentries.networking.istio.io to mesh administrators, or switch waypoints back to hostname addressing.
5. After upgrading, test the bypass is gone from a pod inside the mesh, against a path your DENY rule covers:

curl -s -o /dev/null -w "%{http_code}\n" --http2-prior-knowledge \
  -X post http://orders.shop.svc.cluster.local:8080/admin

A 403 means the rule now matches.

Why it matters

Deny lists in authorization policy depend on the attacker using the same spelling you used. HTTP methods are case-sensitive by specification, so a matcher that compares bytes is technically correct and practically wrong, because the protocol layer in front of it normalizes for one HTTP version and not the other. An allowlist of permitted methods doesn't have this failure mode, which is why it's the safer default for any rule that has to hold.

The istiod bug shows a different lesson. In a shared mesh, a namespace-scoped permission like creating a ServiceEntry can reach a cluster-wide component. When you review RBAC for tenants, count what each resource type can do to the control plane, not just to the tenant's own namespace.

Try it yourself

Run the jq query above against one cluster and list every policy it returns. For each one, write the equivalent ALLOW policy with an explicit methods list and apply it in a staging namespace. Then send the lowercase HTTP/2 request on an unpatched staging mesh and confirm the allowlist blocks it.

Quick check

Sources

• Istio: ISTIO-SECURITY-2026-007
• Istio security bulletins index
• Envoy security advisories