Istio fixes HTTP/2 method-case authorization bypass

A DENY rule naming POST could fail to stop an HTTP/2 request using post. ISTIO-SECURITY-2026-007, published October 15, explains that AuthorizationPolicy method rules compiled to case-sensitive matchers. The patch makes method matching case-insensitive. The affected policy forms matter because a failed positive match and a failed negative match can produce different access decisions.

The same bulletin fixes an ambient-mode denial of service involving a service claiming the address of an IP-addressed waypoint. A tenant able to create a ServiceEntry in its own namespace could trigger a panic in istiod and stop configuration distribution and certificate rotation across the mesh. The two findings concern separate mechanisms, with different prerequisites and different operational consequences.

My view of Istio remains grounded in workload identity and explicit enforcement. After five years with it, uniform policy across services is useful enough to justify an additional distributed system in the right fleet. These findings show why policy compilation and control-plane input handling belong in that assessment. A namespace-scoped declaration can influence a shared controller, and a correctly named method can still become an incorrectly implemented rule.

Case-sensitive matching interacted with policy negation

The method-case advisory identifies DENY rules using methods and ALLOW rules using notMethods. An HTTP/2 method differing only in case did not match the generated :method matcher. In those policy forms, the mismatch could permit forwarding to the workload.

A simple positive method allowlist has different behavior. If an ALLOW rule explicitly permits POST, a case-mismatched method fails to match the allowlist. The advisory states that policies using only ALLOW rules with explicit method lists are not affected. This is why the policy structure needs to remain part of the exposure description.

The distinction can be illustrated by the operation fields, without presenting a complete policy:

# Operation in a DENY rule that the advisory identifies as affected
methods: ["POST"]

# Operation in an ALLOW rule that the advisory identifies as affected
notMethods: ["POST"]

These fragments describe the relevant rule forms. Their final authorization result still depends on the surrounding policy resources and the request. The vulnerability is the case-sensitive interpretation of the method when the policy's exclusion logic lets a mismatched spelling avoid the intended restriction.

HTTP/1.1 is not affected by this issue because its codec rejects non-uppercase methods before authorization. HTTP/2 reaches the matcher with the differently cased method. The protocol therefore changes which input reaches the policy implementation, even when the configured rule is identical. A test using only HTTP/1.1 cannot establish behavior for the vulnerable path.

The correction belongs in the generated matcher. Applications do not need a new spelling convention for the same policy field. Existing rules need the implementation to evaluate method case consistently with the security behavior described by the fix. The advisory recommends explicit ALLOW method lists as an interim measure while the affected components are being patched.

A global address index accepted a namespace-local collision

The waypoint collision advisory gives a concrete implementation explanation. In ambient mode, istiod finds the service owning an IP-addressed waypoint through a key consisting of network and IP address. The key does not include namespace. Another service declaring the same address can therefore appear in the same lookup result.

The EDS shim used krt.FetchOne over the service-address index. When the lookup returned more than one service, it panicked on a controller goroutine. The advisory identifies the failed assumption directly in the panic text about finding more than one item. The controller expected uniqueness where another permitted resource could create a duplicate.

The colliding resource survives the process. Restarting istiod therefore does not remove the cause, and the controller crash-loops until the resource is deleted. The patch skips colliding addresses with a warning. That changes ambiguous input from an unhandled process failure into a reported configuration problem.

This is a cross-namespace denial of service because the address lookup is shared. A user does not need permission to edit the waypoint itself. The advisory describes creating a ServiceEntry in any namespace with the waypoint's address. Permission to submit that resource in one namespace is enough to introduce the colliding entry into the shared index.

The scope is narrower than all ambient installations. The waypoint must report an IP address, for example through the networking.istio.io/address-type: IPAddress annotation. Hostname-addressed waypoints are not affected by this collision path, and hostname reporting is the default. The bulletin also identifies untrusted ServiceEntry creation as the relevant tenant capability.

A control-plane crash has continuing consequences

The advisory says configuration distribution and certificate rotation stall across the mesh. That is a broader consequence than rejecting the tenant's own resource. It does not establish that every existing application connection immediately stops, but it does stop the shared control plane from performing those ongoing operations.

The persistence explains why resource removal is part of the interim recovery. Replacing a crashed process while retaining the colliding declaration lets the same lookup fail again. Restricting ServiceEntry create and update permissions to trusted administrators limits who can introduce the trigger. Using hostname-addressed waypoints avoids the affected address-resolution path.

The patch's warning also preserves diagnostic evidence. A controller that encounters ambiguous ownership needs a defined result that can be associated with the conflicting configuration. Terminating the process makes that one invalid assumption affect unrelated tenants. Skipping the collision keeps the input problem from becoming a mesh-wide configuration-distribution outage.

For me, this reinforces the distinction between API authorization and controller robustness. Namespace permissions define which resources a tenant can submit. The controller still has to handle every allowed declaration without assuming global uniqueness that those permissions do not enforce. Both are necessary when a shared control plane consumes tenant-controlled configuration.

Supported release lines receive coordinated patches

The bulletin identifies Istio 1.31.0 through 1.31.1, 1.30.0 through 1.30.5, and 1.29.0 through 1.29.8 as affected releases. It directs users to 1.31.2, 1.30.6, or 1.29.9 as appropriate. The 1.29 patch is the final release on that line, which reaches end of life on October 15. Its users also need a plan to move to a newer supported line.

The 1.31.2 release notes describe additional security fixes. Istioctl now verifies the istiod certificate when using a service-account token for xDS connections. The expected server name comes from the configured authority, a DNS xDS address, or the istiod service name when connecting through an IP address or localhost.

That correction concerns authenticating the control plane to the diagnostic client. Possession of a service-account token authenticates the client in the other direction. The two operations do not replace each other. The notes provide an explicit insecure opt-out, which makes disabling server verification a deliberate compatibility choice rather than an implicit behavior.

The Wasm OCI fetcher also stops retrying failed HTTPS requests over plaintext HTTP unless the registry appears in WASM_INSECURE_REGISTRIES. Previously, an untrusted registry error could trigger the fallback. Without an optional pinned module digest, a malicious registry or intermediary could then supply an arbitrary binary. The patch puts the insecure transport exception under operator control.

These fixes are distinct from the method matcher and waypoint panic, but they share a need for explicit failure behavior. A failed secure fetch cannot establish permission for plaintext transport. A duplicate service address cannot establish unique ownership. The implementation must decide what to reject or constrain when the configuration and runtime evidence do not support the requested operation.

Debug lookups receive an exact-match correction too. The release notes say a partial proxyID could previously match other proxies in the same namespace through substring matching. The corrected endpoints require the exact pod-and-namespace identity or a full connection ID. This narrows lookup behavior without changing the separate namespace authorization requirement. Diagnostic tools relying on abbreviated IDs must now supply the actual target identity.

The update covers proxy filters as well

The Envoy portion fixes crashes in the OAuth2 and API-key authentication HTTP filters when handling CONNECT requests without a :path header. Their relevance depends on using those filters. Absence of an IP-addressed waypoint does not exclude exposure to these separate proxy paths.

The October update therefore needs an inventory tied to mechanisms. Method policy forms and HTTP/2 determine one authorization exposure. Ambient waypoint addressing and ServiceEntry permissions determine the control-plane collision exposure. The configured authentication filters determine another set of affected requests. The published patches correct these implementations while retaining the existing policy and resource interfaces.