Istio patches DNS cache lifetime and OAuth2 logout failures

A security update to a general-purpose proxy can cover unrelated failure mechanisms. One request path may corrupt memory during DNS processing, while another fails to remove a browser session cookie. Combining them under one severity heading is useful for release coordination, but an operator still needs the conditions and effects of each issue.

The September 3 Istio advisory includes CVE-2025-54588, a use-after-free in Envoy's DNS cache, and CVE-2025-55162, an OAuth2 signout cookie problem. Its affected Istio releases are 1.27.0, 1.26.0 through 1.26.3, and 1.25.0 through 1.25.4. Configuration determines whether a deployment uses the relevant vulnerable path.

I accept the complexity of Istio when workload identity and shared traffic controls justify it. That includes tracking the Envoy behavior those controls depend on. A mesh release version is useful inventory, but it does not tell me which optional filters have been placed in a gateway's request path.

The DNS cache issue involves callback-driven mutation

The Envoy DNS advisory describes abnormal process termination caused by a use-after-free. While a pending DNS resolution completes, its callback can trigger more resolutions or remove existing pending resolutions. That mutation can reallocate memory while an iterator still refers to the earlier allocation.

This is a lifetime problem in asynchronous processing. The callback runs as part of completing an earlier operation, but it can also modify the collection that the completion path is traversing. If the traversal assumes its references remain valid throughout the callback, that assumption can fail without any ordinary DNS lookup returning an error.

The advisory names specific conditions. The Dynamic Forwarding Filter is enabled, the dfp_cluster_resolves_hosts runtime feature is enabled, and the Host header changes between the Dynamic Forwarding Filter and Router filters. It dates the affected implementation to Envoy 1.34.0 onward in the listed branches.

Those conditions explain why the label DNS cache alone is too broad. The issue is not a statement that every DNS resolution performed by Istio can trigger the same failure. It concerns a particular dynamic-forward-proxy flow in which later processing can change the host that needs resolution.

Istio's advisory directs attention to deployments using an EnvoyFilter with dynamic_forward_proxy. That is the mesh-level exposure clue. The detailed Envoy conditions then narrow the mechanism within the proxy configuration. Both sources are useful because an operator's declared Istio resource and Envoy's runtime filter arrangement are different representations of the same request path.

The documented impact is availability loss

Envoy assigns the DNS issue a CVSS score of 7.5 and describes denial of service through abnormal process termination. That is the documented effect. A use-after-free is a serious memory-safety failure, but the advisory does not establish remote code execution for this issue.

The distinction matters for incident interpretation. A proxy crash can interrupt the traffic handled by that process. It does not by itself prove disclosure of application data or takeover of the node. Describing the impact accurately helps keep the response tied to evidence from this vulnerability.

The upstream workaround disables envoy.reloadable_features.dfp_cluster_resolves_hosts. The advisory gives this as a runtime configuration change for the relevant feature. It should be understood as a specific alternative while applying the upstream repair, not a general instruction to disable DNS or remove every dynamic-forward-proxy use.

The same advisory identifies DispatcherImpl::runPostCallbacks in an abnormal termination stack as a detection clue. That can support diagnosis when the proxy configuration matches the stated conditions. It is not a substitute for checking the running version, and the absence of such a crash does not prove the vulnerable path is absent.

OAuth2 logout fails at the browser's cookie rules

The OAuth2 advisory concerns cookie names beginning with __Secure- or __Host-. Those prefixes require the Secure attribute when the browser accepts the cookie. The requirement also applies when a response attempts to delete it.

Cookie deletion is expressed by another Set-Cookie response with an expired value. The vulnerable OAuth2 filter generated that deletion without the required Secure attribute for prefixed names. A browser rejects the instruction, so the original session cookie remains present.

The following header illustrates the missing attribute described by the advisory. It is an example of the incorrect deletion response, not a configuration to deploy.

Set-Cookie: __Secure-id-token=deleted; Expires=Thu, 01 Jan 1970 00:00:00 GMT

The corrected form retains the attribute required by the prefix. The expiration date expresses deletion, while Secure makes that instruction acceptable under the prefixed-cookie rule.

Set-Cookie: __Secure-id-token=deleted; Expires=Thu, 01 Jan 1970 00:00:00 GMT; Secure

This is a state transition the browser can refuse. Receiving a logout response does not establish that the browser discarded the credential. A server-side handler can execute its signout route successfully while the client's session material remains available for later requests.

The advisory assigns the issue a score of 6.3 and identifies shared or public computers as a particular risk. A person believes they have logged out, but a subsequent browser user can inherit the still-active session. The failure therefore concerns the meaning of logout to the user, not only the syntactic correctness of a response header.

Prefix requirements apply to deletion as well as creation

The OAuth2 filter allows configured names for several cookies, including token and HMAC cookies. Upstream's example uses prefixed names across those settings. The exposure depends on that configuration, which is why using the affected Istio version alone does not establish this particular failed-logout path.

The root error is treating deletion as a special operation exempt from the cookie's acceptance constraints. In HTTP, deletion still uses a cookie-setting instruction. The browser evaluates whether that instruction is valid before using its expiration date to remove existing state.

I consider the browser's retained state the relevant outcome here. An access log that records a successful signout route cannot answer whether the credential disappeared. The security property belongs to the next authenticated interaction as well as the response that claimed to end the session.

Avoiding prefixed-cookie configuration is one mitigation listed upstream, while applying the fix preserves the intended naming scheme. Those options have different effects on deployment configuration. A patch corrects the deletion behavior so that the existing prefix contract remains usable.

The Istio repair needs to reach the proxy implementation

The Istio 1.27.1 release notes explicitly say the patch implements the September security updates. That provides a release-level repair reference for the 1.27 branch. The Istio version ranges in the security advisory should be used for mesh inventory, while Envoy's own version numbers describe upstream proxy releases.

Those numbering systems are not interchangeable. Installing an Envoy release number as if it were an Istio version would not be a meaningful upgrade instruction. The relevant mesh patch packages the proxy changes into the distribution the installation actually uses.

The 1.26.4 patch announcement also explicitly implements the September advisory. This establishes a repair on that maintained minor branch, without requiring the conclusion that the security fix exists only in 1.27.1. Selecting a branch and verifying its security patch are related but separate release-management decisions. The version range in the advisory identifies the old boundary, while the patch announcement identifies the concrete new artifact for that branch.

These patch releases also carry nonsecurity fixes. Both announcements describe a problem where IPv6 state could take precedence over IPv4 state when deciding whether to apply redirection rules. That repair affects the correspondence between configured capture and installed rules, independently of the DNS-cache callback failure. Seeing an interception change after upgrade should therefore not automatically be attributed to a security workaround. The release contains more than the two CVEs, and its individual changes explain different observations in the proxy and node networking configuration.

The two issues also need different outcome evidence. For the dynamic-forward-proxy path, the repaired implementation must handle the stated resolution and header-change conditions without abnormal termination. For OAuth2 signout, the deletion response must satisfy the cookie rules and remove the relevant session cookies. Both are part of the September update, but they protect different properties of the traffic path.

The advisory therefore supports a configuration-specific assessment. A deployment can identify the affected proxy version and determine whether it uses dynamic_forward_proxy or prefixed OAuth2 cookies. The corresponding patch then repairs the implementation, preserving the intended forwarding or logout behavior without treating unrelated mesh traffic as evidence that either vulnerable path is exercised.