Istio's October security patch fixes two buffer-related crashes
Oversized Lua response rewrites and connection shutdown during flow control expose different Envoy failures. Both require fixing lifetime handling inside the proxy.
A buffer limit should bound resource use, and closing a connection should end its activity cleanly. Both operations also trigger callbacks and state transitions inside a proxy. Istio's October security update covers two cases where those transitions could access state whose lifetime no longer matched the operation in progress.
The October 20 Istio advisory describes CVE-2025-62504 in Lua response processing and CVE-2025-62409 in TCP connection-pool flow control. An oversized rewritten response triggers the first path. The second involves a closing connection while upstream data is still arriving. Their common documented outcome is an Envoy crash.
The advisory's summary table mistakenly repeats the September CVE identifiers, while its body names the October issues above. The upstream CVE records confirm the body identifiers and mechanisms. Those records are the appropriate references for distinguishing this update from September's DNS-cache and OAuth2 fixes.
I regard these as part of the operational cost of extending proxy behavior. Moving a transformation into Envoy can centralize application policy, but it also makes the transformation depend on Envoy's buffering and callback implementation. The response path needs the same attention as the declared filter configuration.
A rewritten response can cross a limit after it arrived
The CVE-2025-62504 record describes a Lua script executing in the response phase. The script rewrites the body until it exceeds per_connection_buffer_limit_bytes, whose documented default in the record is one megabyte. Envoy then generates a local reply.
The memory-safety problem occurs when that local reply replaces the original response headers. References associated with the earlier response remain, and the resulting dangling references lead to a crash. The problem therefore includes the proxy's error response to the limit, not merely the fact that a script produced too much data.
This distinction makes the mechanism more informative than a warning about large payloads. The same initial upstream response can have a different size after a Lua transformation. A limit checked against the transformed result can activate behavior that a small unmodified response would never exercise.
The upstream record classifies the issue as use-after-free and documents denial of service. It identifies patched Envoy releases including 1.36.2 and 1.35.6. Those are upstream proxy versions, which should not be confused with Istio's release numbering.
Increasing buffer limits can reduce how often a deployment encounters the condition. The record explicitly says this does not repair the memory-safety flaw. A larger threshold moves the point at which the faulty transition occurs and can increase memory committed to buffering. It is not equivalent to fixing the lifetime of the response state.
For HTTP/2, the upstream record also mentions the initial stream window among the settings relevant to reducing the likelihood of a trigger. That reinforces the scope of the workaround. It concerns buffering and flow-control conditions, without changing the underlying code that holds references during local-reply generation.
A closing connection can still have data callbacks
The CVE-2025-62409 record identifies a null-pointer reference in a buffer-watermark callback. Large requests and responses can exercise flow control while a connection is closing and upstream data continues to arrive.
The record scopes the issue to TCP proxying and mixed HTTP/1 and HTTP/2 use cases based on ALPN. It does not describe every HTTP request as having the same exposure. The relevant combination includes the protocol path and the timing of shutdown relative to remaining data.
A shutdown operation does not mean that every outstanding callback has already disappeared. The reported failure shows why a flow-control callback needs valid connection state or a safe way to observe that the state is gone. A null reference in that interval can terminate the process even if the connection would otherwise have closed normally.
This is different from the Lua issue's rewritten-body limit. One error path replaces response state during local-reply generation. The other occurs during connection-pool shutdown and continued data handling. They both concern lifetime, but a workaround directed at a Lua transformation does not establish protection for the TCP pool.
I consider that distinction useful when interpreting a crash report. A large payload is a condition shared by several paths, not a diagnosis. The stack and configured filters identify which part of the implementation handled the transition that failed.
The mesh patch packages the upstream repairs
The Istio 1.27.3 announcement says it implements the October advisory and introduces no other changes. That provides a concrete Istio release for the repair, while the CVE records explain the behavior of the underlying Envoy implementation.
This separation is important for inventory. A Lua filter may be introduced through an EnvoyFilter resource, while the process running it comes from an Istio proxy image. The resource describes a use of the capability. Its execution depends on whether the image includes the repaired memory handling.
Both upstream records were public on October 16, before this Istio announcement. That timing allows the mesh advisory to be read alongside the fuller mechanism descriptions. It also prevents the publication date of the mesh patch from being mistaken for the first public description of either upstream vulnerability.
The Istio advisory specifically calls out Lua via EnvoyFilter for the oversized-response case. Its TCP description instead concerns large traffic with data arriving during connection closure. An installation can exercise one path without using the other, so it needs the appropriate configuration context for interpreting each finding.
Neither record establishes remote code execution or data disclosure for these issues. The documented crashes are availability failures. That is still significant for a proxy handling multiple application connections, but the impact should be stated according to the source.
The repair is an implementation change that preserves the intended proxy operations. Lua can still transform responses within the configured handling rules, and flow control still manages data while connections change state. The patch corrects the transitions around those operations so that exceeding a limit or closing a connection does not turn into invalid memory access and process termination.