Istio patches memory accounting in the HTTP/3 decoding path

An HTTP/3 decoder can retain bytes after the transport has stopped counting them against receive flow control. ISTIO-SECURITY-2026-005, published June 24, describes exactly that failure during blocked QPACK decoding. A header block waiting for dynamic table updates retained its payload in a decoder heap buffer while QUIC receive accounting treated those bytes as released. A remote peer could consequently drive unbounded memory growth.

The corresponding patch releases are Istio 1.30.2, 1.29.5 and 1.28.9. All three release notes are dated June 24 and list the security update. The bulletin's affected-release table includes these patch versions in its ranges, so that table is inconsistent with the release notes. The release notes identify them as carrying the fixes.

Istio's workload identity model is the part I value most. Moving traffic policy into shared infrastructure can also be useful across a large fleet. The cost is operating another distributed system whose proxy behavior needs its own attention. This bulletin concerns that proxy implementation, and its detailed entries are Envoy security fixes. Its generic subtitle is insufficient evidence of a separate Istio-specific vulnerability.

Retained memory needs an owner in the accounting

The QPACK issue has an important property. The bytes were still present in memory even though a lower layer considered them consumed. Progress through one layer did not mean the entire system had finished with the data. Flow control therefore stopped providing an effective bound on what the decoder retained.

That mechanism explains the denial of service more precisely than a general statement that large headers use memory. A limit can work only if the resource being limited remains represented in its accounting. Transferring responsibility between layers requires either continued accounting at the first layer or an effective bound at the next one.

The bulletin assigns this issue a CVSS score of 7.5 and identifies it by GHSA-p7c7-7c47-pwch. Its described consequence is an out-of-memory condition. That is a specific availability failure. The entry does not claim that this QPACK bug reads another workload's data or changes its authorization policy.

For operators, the distinction helps connect the advisory to the relevant behavior. The entry concerns the HTTP/3 stack and blocked QPACK header decoding. It should not be expanded into a claim that every request through every mesh mode exercises the same path. The source describes a particular mechanism, which is the proper basis for assessing its relevance to a configured proxy.

A decompression limit checked too late has a similar problem

The bulletin separately lists CVE-2026-48044 in the Zstd decompressor. Its MaxInflateRatio check ran after an entire input slice had been processed. A crafted slice could expand to hundreds of megabytes within one process() call before the limit was checked.

The fix moves enforcement into the inner decompression loop. It stops as soon as the threshold is breached, matching the behavior described for the gzip and brotli decompressors. The location of the check is therefore part of the security property. Having a configured ratio limit was insufficient when one unit of processing could allocate a large amount before evaluating it.

This provides a second concrete example of why resource limits need a precise enforcement point. The QPACK failure released accounting while memory remained live. The decompressor retained a check but applied it after too much work. Both permitted memory consumption to outrun the mechanism intended to constrain it, although their implementations and triggers differ.

That is relevant to how I judge shared traffic infrastructure. A proxy adds code that processes requests before application code can reject them. Its resource accounting belongs in the operational model alongside its routing and identity configuration. The policy can be correctly configured while the parser or decoder implementing a protocol still needs a security patch.

Asynchronous filters have lifetime requirements

CVE-2026-47205 concerns a use-after-free crash in the external authorization filter. The described combination includes per-route service overrides and a downstream connection reset during an authorization check in flight. Another entry, CVE-2026-48090, concerns a token-change callback running after the filter's destruction path.

These entries illustrate a different failure mechanism from memory exhaustion. An asynchronous callback needs a valid target for as long as it may run. A downstream request disappearing does not necessarily mean all callbacks related to that request have already stopped. Destruction and cancellation therefore need a consistent lifetime protocol.

The bulletin also lists a crash or use-after-free in gRPC statistics tracking on a direct response route. Its description is narrower than a claim that all gRPC statistics collection is unsafe. The route and filter conditions are part of the reported issue, and the patch notes preserve those conditions for readers assessing exposure.

Grouping these as lifetime bugs is useful analysis, but it does not establish that they share a root cause or one mitigation. Each entry identifies a distinct path. A fix for the decoder's memory growth supplies no evidence that one of these callback paths has been repaired, which is why the complete patch release matters beyond its lead issue.

Certificate identity depends on exact parsing

CVE-2026-47778 describes Subject Alternative Name validation when the name contains an embedded NUL byte. The bulletin says truncation in some configurations could produce an incorrect trust decision. The relevant distinction is between the certificate's encoded name and the name the validator actually compares.

This directly concerns what I find useful about workload identity. Attaching identity to certificates is a sound basis for policy only when the implementation interprets those certificates consistently. A comparison performed on a truncated representation can answer a different question from the one the certificate presents.

The advisory does not establish a universal authorization bypass across every Istio configuration. It identifies a parsing weakness with configuration-dependent consequences. Keeping that scope explicit makes the explanation more useful than translating every certificate-validation entry into the broadest possible security claim.

Protocol validation changes have explicit controls

The security update also fixes HTTP/3 headers-only request and response content-length validation in CVE-2026-48743. An inconsistent length now causes the stream to reset. Its runtime guard is envoy.reloadable_features.quic_validate_headers_only_content_length, as named in the bulletin.

Another entry, CVE-2026-48042, limits JSON nesting depth to 1,000. Its named runtime guard can relax that limit to 10,000 when disabled. These are concrete behavioral details in the patch, so the presence of the fixed binary and the selected runtime behavior both matter when explaining what a deployment does.

The OAuth2 filter update addresses a padding oracle in AES-256-CBC cookie decryption. The bulletin describes support for AES-256-GCM with a gcm. marker to authenticate ciphertext. That entry concerns a specific filter and cookie encryption mechanism. It should be assessed separately from the HTTP/3 issues that motivate the headline.

The release notes distinguish security and robustness work

The 1.30.2 notes include other changes outside their security section. One fixes a brief traffic outage when a Kubernetes Gateway or ListenerSet changes its istio.io/rev label. The previously owning control plane now avoids sending empty xDS configuration to gateway pods still using its revision.

The same notes describe an ambient health-probe issue after a node or kubelet restart. The node agent now reasserts the relevant probe ipset membership during reconciliation. These are operational robustness fixes in the release notes. Their presence alongside security patches does not make them additional vulnerabilities listed by the bulletin.

That separation is useful when reading a patch release. It tells an operator which symptoms the release addresses without inventing a security classification. The 1.29.5 notes carry overlapping robustness changes, while 1.28.9 presents its security update directly. The three documents should be read as their own release records.

The gateway revision fix also shows why a control-plane ownership transition needs to account for proxies still using the previous configuration. Changing the resource label and changing every consuming process happen at different times. The release notes describe preserving useful configuration during that interval.

For June 24, the concrete release choice is documented despite the bulletin table's inconsistency. Version 1.30.2 carries the security update on its line, with 1.29.5 and 1.28.9 carrying it on theirs. The principal HTTP/3 fix closes a gap between retained decoder memory and flow-control accounting, while the other entries address their separately described filters, parsers and protocol behavior.