Istio AuthorizationPolicy Bypass: HTTP/2 Method-Case Bug

Originally published on DevToolHub.

Istio AuthorizationPolicy rules that block or allow traffic by HTTP method just got a real asterisk. ISTIO-SECURITY-2026-007 fixes a case bug in that matcher. Published October 15, 2026, it covers one specific issue: an HTTP/2 request with a lowercased method name could slip past a method-based rule entirely. If you run DENY rules with methods, or ALLOW rules with notMethods, check this today. Don't wait for your next patch window.

What ISTIO-SECURITY-2026-007 Fixes in Istio AuthorizationPolicy

The advisory bundles five fixes. The loudest is a critical Envoy Brotli decompressor buffer overflow, CVE-2026-111497 (CVSS 9.2). Two Envoy crash bugs on CONNECT requests without a :path header (GHSA-8vc2-jrm4-835w, CVSS 7.5, and GHSA-47vj-9r25-wv5j, CVSS 6.5) and an ambient-mode istiod denial-of-service bug (GHSA-7p2q-4xvg-vxc6, CVSS 7.7, IP-addressed waypoints only) round it out.

The other is the one this piece covers: GHSA-w44g-8m76-8gc5, CVSS 7.4 (High). Istio titled it "AuthorizationPolicy method rules are bypassed over HTTP/2 by changing the method case."

There's no CVE number attached to this one yet. Only the GHSA ID exists, so don't expect it in a CVE search anytime soon. The affected range is 1.31.0–1.31.1, 1.30.0–1.30.5, and 1.29.0–1.29.8.

How the HTTP/2 Method-Case Bypass Works

An Istio AuthorizationPolicy can use a DENY rule with methods, or an ALLOW rule with notMethods. Both compile down to an Envoy :method matcher. That matcher is case-sensitive. So a rule meant to block POST only checks for the literal uppercase string POST.

Here's where the codecs diverge. Envoy's HTTP/1.1 codec normalizes and rejects non-uppercase methods before the request reaches the authorization filter. A lowercase post never even gets to test the policy. HTTP/2 doesn't enforce that same restriction at the codec layer. A request arriving as post instead of POST passes straight through the case-sensitive matcher. The policy that was supposed to block it does nothing.

That's the whole bug. One protocol enforces method casing before policy evaluation; the other doesn't. The policy logic assumed both would behave the same way. Policies that only use ALLOW rules with an explicit methods list aren't affected. The request still has to match an allowed value to get through. The negative-match cases — DENY + methods, ALLOW + notMethods — are different: there, a non-match means "let it through."

Why Istio AuthorizationPolicy Bypasses Keep Happening

This is at least the fifth time a matching-logic gap has let traffic slip past an Istio AuthorizationPolicy rule. Every time, the rule was supposed to catch it. Each one has been a different field. But the shape of the bug is the same: the policy compiler assumes a normalized value. Somewhere downstream, that assumption breaks.

• CVE-2020-16844 (ISTIO-SECURITY-2020-009, CVSS 6.8) — DENY rules with wildcard suffixes on source principals or namespaces never denied TCP callers.
• CVE-2021-39155 (ISTIO-SECURITY-2021-008) — the Host header comparison was case-sensitive, even though RFC 4343 says hostnames should compare case-insensitively. That gap let Httpbin.Foo bypass a rule written for httpbin.foo.
• CVE-2021-39156 (same ISTIO-SECURITY-2021-008 advisory) — a #fragment appended to a request path could bypass path-based authorization checks.
• CVE-2022-21679 (ISTIO-SECURITY-2022-001, CVSS 6.8) — mixing a 1.12 control plane with 1.11 data plane proxies broke hosts and notHosts matching.

None of these are the same code path. But they're all the same category: a string comparison in an AuthorizationPolicy field that quietly assumed normalized input. If you've treated method, host, or path matchers as airtight, this history says otherwise.

Who Is Affected: Versions and Deployment Modes

You're exposed if two things are both true. Your Istio AuthorizationPolicy rules use DENY with methods, or ALLOW with notMethods. And clients can reach the workload over HTTP/2.

That covers both sidecar mesh deployments and ambient mode. Both enforce L7 authorization through Envoy proxies that speak HTTP/2 to upstream services and to each other.

It doesn't matter whether the attacker is external or an already-compromised pod elsewhere in the cluster. The bypass works the same way either direction. That's exactly why relying on a single enforcement layer is risky. Our guide on Kubernetes node pools and networking is useful here too. It maps where traffic actually flows before you decide where policy should live.

Patched Versions and the Upgrade Path

Istio shipped fixes in 1.31.2, 1.30.6, and 1.29.9. The 1.29 branch's fix is also its final release. That line is done taking patches. Treat 1.29.9 as a stopgap, and plan your move to 1.30 or 1.31 regardless.

Roll the whole mesh, not just the control plane. The same release carries Envoy fixes, so restart your sidecars — or ztunnels and waypoints, on ambient — to pick up the patched proxy build, and don't stop at istiod.

How to Audit Your Istio AuthorizationPolicy Rules Right Now

You don't need to wait for a scanner to tell you if you're exposed. Pull every policy in the cluster and grep for the two fields that matter:

kubectl get authorizationpolicies.security.istio.io -A -o yaml | grep -B5 -E "methods:|notMethods:"

For each hit, check the action field on that policy. If it's DENY and lists methods, or it's ALLOW and lists notMethods, that rule relied on a case-sensitive match. HTTP/2 traffic could dodge it until you upgraded. If every method-based rule you find is an ALLOW with an explicit methods list, you were never affected. Patch anyway — the next matcher bug in this list might also hit a different field.

Mitigations If You Can't Upgrade Yet

The cleanest workaround doesn't need a code change to Istio at all. Rewrite DENY + methods rules as ALLOW rules with an explicit, uppercase methods list instead. Per the advisory itself, policies that only use ALLOW with an explicit methods list were never affected. A request still has to match a listed value to get through. There's no negative-match gap to exploit.

If you can't restructure the policy quickly, you can also restrict which workloads accept HTTP/2 from untrusted sources. That's a narrower fix than it sounds. gRPC and most modern service-to-service traffic run on HTTP/2 by default. Upgrading is still the actual fix; the policy rewrite is a bridge, not a replacement.

The Takeaway: Don't Rely on Istio AuthorizationPolicy Alone

Five bypasses across six years in the same subsystem is a pattern, not bad luck. That's a reasonable argument for not putting all your access control eggs in one AuthorizationPolicy basket. Layer a Kubernetes NetworkPolicy underneath your mesh's L7 rules. That way, a matcher bug at the application layer doesn't also mean the connection itself was never restricted.

Runtime visibility helps too. A tool like Falco can flag unexpected traffic at the kernel level, no matter what Envoy's policy layer missed. If you're studying for a Kubernetes security certification, our CKA vs CKAD vs CKS breakdown covers the access-control picture. It shows where authorization and network segmentation fit into the certification track.

For now: patch to 1.31.2, 1.30.6, or 1.29.9. Audit your existing Istio AuthorizationPolicy rules for DENY+methods or ALLOW+notMethods. And don't treat method-based policy as your only line of defense.

Frequently Asked Questions

Q: Does this bug have a CVE number?
A: Not as of this advisory's publication. It's tracked only under the GitHub Security Advisory ID GHSA-w44g-8m76-8gc5, CVSS 7.4 (High). A CVE may get assigned later, but don't rely on a CVE-only vulnerability feed catching it yet.

Q: Is my cluster affected if I only use ALLOW rules with an explicit methods list?
A: No. The advisory is specific: ALLOW rules with an explicit methods list were never affected. It still has to match a value in that list. The bug only hits the negative-match cases: DENY with methods, or ALLOW with notMethods.

Q: Does HTTP/1.1 traffic need the same audit?
A: No, not for this specific bug. Envoy's HTTP/1.1 codec rejects non-uppercase methods before the request reaches the authorization filter. So the case-mismatch bypass doesn't apply here. HTTP/2 is the exposed path.

Q: Are the other fixes in the same advisory related to this bypass?
A: No. ISTIO-SECURITY-2026-007 bundles five separate fixes: this method-case bypass (GHSA-w44g-8m76-8gc5), a critical Envoy Brotli overflow (CVE-2026-111497), two Envoy CONNECT crash bugs, and an ambient-mode istiod denial-of-service bug (GHSA-7p2q-4xvg-vxc6) that needs an IP-addressed waypoint. They're unrelated to each other, and patching to the fixed versions covers all of them.

Quick Summary:

• ISTIO-SECURITY-2026-007 (Oct 15, 2026) fixes GHSA-w44g-8m76-8gc5, CVSS 7.4 — no CVE assigned yet
• The bug: Istio AuthorizationPolicy's :method matcher is case-sensitive, so HTTP/2's lowercase methods slip past DENY/notMethods rules
• Affected: DENY rules with methods, or ALLOW rules with notMethods, on 1.31.0–1.31.1, 1.30.0–1.30.5, 1.29.0–1.29.8
• Not affected: ALLOW rules with an explicit methods list
• Patched in 1.31.2, 1.30.6, and 1.29.9 (1.29's final release — plan your move off that branch)
• Same advisory also fixes a critical Envoy Brotli overflow (CVE-2026-111497, CVSS 9.2) — the upgrade covers it
• This is the fifth AuthorizationPolicy matching bypass in Istio's history (CVE-2020-16844, CVE-2021-39155, CVE-2021-39156, CVE-2022-21679) — treat method/host/path matchers as a layer, not the whole wall, and back them with NetworkPolicy and runtime detection

The real fix is upgrading. But if this is the fifth time a string comparison inside Istio AuthorizationPolicy has let traffic through it shouldn't have, the bigger lesson is to stop treating that one policy object as your only gate.