Istio 1.22.3 repairs two different HTTP state failures
The July patch updates Go's HTTP client and Envoy's route hash-policy handling. Their failure mechanisms differ, so the release needs to be understood across both dependency boundaries.
An HTTP proxy depends on state that persists beyond the immediate request, including reusable connections and parsed routing configuration. Istio 1.22.3 updates dependencies after defects in both kinds of state. The July 16 release notes name Go's CVE-2024-24791 and Envoy's CVE-2024-39305. They arrive together in the mesh release, but they describe different implementations and different failure mechanisms.
The Go defect leaves an HTTP/1.1 client connection in an invalid state after a particular response to Expect: 100-continue. The Envoy defect keeps references to cookie-attribute memory after that memory has been freed. One can make a later request fail on a reused connection. The other can disclose process memory to an upstream or terminate the proxy. Treating both as generic HTTP denial of service would lose information needed to understand exposure.
I see these updates as part of the cost of placing another distributed system in the request path. Istio's policy model does not replace dependency maintenance. The compiled implementation of the control plane and the proxy's routing machinery each bring their own security behavior into the installation.
Go mishandles a final response before the body
The Go vulnerability report, published July 2, describes an HTTP/1.1 client handling a request containing Expect: 100-continue. Instead of an informational response, the server sends a status of 200 or greater. The client mishandles that case and can leave the connection unsuitable for its next request.
The security effect becomes visible in a Go reverse proxy. An attacker sends a request that elicits the affected response from the backend. That request leaves a bad connection in the reusable set, and one subsequent request using it fails. The report describes denial of service through this sequence. The failed request need not be the one carrying the original triggering header.
That distinction makes connection reuse central to the mechanism. A request's effect can extend to later traffic because the client maintains transport state beyond one exchange. A backend response that completes the current exchange must leave the connection in a state consistent with future reuse. The bug violates that expectation under the reported header and response conditions.
The Go report identifies repairs in 1.21.12 and 1.22.5. Istio's release note says its Go version has been updated to include the relevant fix. This is a build dependency change, so the repaired implementation must be present in the binaries distributed by the release. An operating-system setting cannot substitute for the code change inside an already built Go program.
The primary report illustrates exploitation using net/http/httputil.ReverseProxy. That establishes the library failure and a concrete attack pattern. It does not by itself prove that every Go component in Istio exposes a reverse-proxy endpoint matching that example. The Istio release includes the security update without assigning every component an identical reachable path.
Envoy retains a reference after parsing ends
The Envoy advisory, published June 28, identifies route hash policies configured with cookie attributes. Memory holding the attribute values is released after configuration parsing. Request processing later attempts to copy from that freed memory into a cookie header sent upstream.
This is an ownership error across two lifecycle stages. Configuration parsing creates data that request processing still expects to use. The parsed representation must preserve that data for as long as requests can reference it. Releasing the allocation while retaining the reference makes the result depend on whatever later occupies the same memory.
The advisory names two possible consequences. Arbitrary contents from Envoy memory can reach the upstream service, or the process can terminate abnormally. The former is an information-disclosure risk even if the proxy keeps running. A review focused only on crash reports could therefore miss the other stated impact.
The affected configuration is also specific. The advisory's workaround is to avoid cookie attributes in route-action hash policy. It does not describe every use of cookies as vulnerable. Request input reaches an unsafe path selected by that routing configuration, which is why both the installed proxy version and the generated route policy matter.
The advisory suggests unexpected cookie-header characters at the upstream as a detection clue. It also identifies hash-policy methods in a crash stack trace. These observations connect the visible symptom to the configured routing path.
I find the ownership boundary more useful than describing this as a malformed-cookie issue. The source says the data was freed after parsing and used later. That explains why a routine request can exercise the flaw when the policy is configured, without requiring a special claim about an attacker corrupting the configuration itself.
One release distributes the dependency repairs
Envoy lists fixed versions in several maintained branches, including 1.30.4. Istio 1.22.3 updates its Envoy dependency to carry the repair. The mesh-level release is the operational artifact for an Istio installation, while the upstream advisory supplies the detailed mechanism and configuration condition.
This distinction matters because replacing only one part of an installation does not necessarily replace every running implementation. Go-built components need the repaired build, and the data plane needs the proxy containing the Envoy fix. The release notes name both dependency updates rather than implying that one policy change repairs them together.
Istio 1.22.3 also fixes delayed recomputation of merged gateway configuration after Service creation or update. Another item corrects inconsistent certificate-expiry metrics, and the release removes JSON access-log sorting pending an Envoy fix. These are separate maintenance changes. They do not alter the conditions described by the two security advisories.
The July update illustrates why a patch release can matter without introducing a new mesh capability. Its dependencies need to preserve valid state across requests and across configuration lifetimes. The Go repair protects connection reuse after a particular response sequence. The Envoy repair protects data retained from configuration parsing and later copied during routing. Both belong in the implementation distributed to the components that execute those paths.