Istio's September fixes expose a private-address trust assumption

A private source address does not establish that a request came from a trusted participant in the mesh. Istio's September 19 security bulletin identifies a default in Envoy that made that assumption. Private addresses were treated as internal, so requests arriving from external sources with private addresses could retain headers that should have been sanitized. The bulletin places this issue beside HTTP/2 crashes and access-log injection, making the release about trust classification as well as availability.

The affected Istio ranges are 1.22.0 through 1.22.4 and 1.23.0 through 1.23.1. The 1.23.2 release carries the security fixes. However, the bulletin also explains that a stricter address-trust default remains disabled for compatibility. Updating the software and selecting that behavior are consequently distinct actions in this release.

I value workload identity because it gives the mesh a basis for authorization beyond network location. A private IP range is a much weaker claim about a request's origin. The September guidance is useful precisely because it identifies an address-based assumption inside the proxy that administrators might otherwise overlook while reviewing higher-level identity policy.

Internal classification affects header handling

The Envoy advisory for CVE-2024-45806 describes RFC1918 ranges being considered internal even when internal_address_config is empty. That classification can let external clients manipulate Envoy headers. The issue is not that a private address is an invalid address. It is that address reachability and administrative trust are different properties.

The advisory gives tooling such as probes as an example of traffic that might intentionally need trusted behavior. Such addresses or CIDR ranges should be configured explicitly. This allows a deployment to describe its actual trusted sources instead of inheriting a broad assumption about all private networks.

The critical question is what the proxy observes at its downstream boundary. An externally initiated request can arrive through infrastructure that presents a private source address. Classifying that request as internal on address category alone transfers trust to traffic that has not earned it through an explicit deployment decision. The advisory therefore concerns the interpretation of a valid connection, not a parser rejecting an invalid packet. A correct connection path can still receive the wrong header-handling policy when the internal-address definition is too broad.

Istio exposes the stricter behavior through runtimeValues in ProxyConfig. The bulletin provides this mesh-wide configuration:

meshConfig:
  defaultConfig:
    runtimeValues:
      "envoy.reloadable_features.explicit_internal_address_config": "true"

The name of the guard should not imply that every associated installation setting changes dynamically. Istio explicitly says ProxyConfig fields require workload restarts to take effect. A stored configuration update without the required replacement of proxy processes is therefore incomplete adoption of this behavior.

The 1.23.2 notes also repair PILOT_SIDECAR_USE_REMOTE_ADDRESS behavior when the guard is enabled. The change supports setting internal addresses to the mesh network instead of localhost so intended sidecar traffic does not undergo unwanted header sanitization. This shows why tightening a trust default needs an implementation that can still represent legitimate internal relationships.

Access-log input is another trust boundary

CVE-2024-45808 concerns the REQUESTED_SERVER_NAME access-log field. The Envoy advisory reports missing validation of that input, allowing unexpected content in logs. It explains that the value can be logged even when RBAC denies the request. Rejecting application access does not prevent all processing of connection-derived diagnostic data.

The examples include newline injection that can create apparent extra log entries and terminal escape sequences that can alter displayed output. These are attacks on how evidence is represented to its consumer. They do not require the request to become an authorized application operation, because the logger still records information about the attempted connection.

The advisory also raises HTML-like input as a possible concern for downstream viewers, without identifying a particular vulnerable viewer. That distinction should be retained. The demonstrated issue is uncontrolled content entering the access log. A claim of script execution in a specific log application would require additional evidence absent from this disclosure.

I consider the logger part of the security boundary because its output informs later operational decisions. An access denial can be correct while the corresponding diagnostic record is misleading. These are independent properties, and the advisory makes clear why enforcing one does not automatically protect the other.

HTTP/2 changes have a different failure mechanism

CVE-2024-45807 addresses crashes in oghttp2 stream handling. The Envoy advisory says Envoy 1.31 uses Oghttp as the default HTTP/2 codec and identifies potential stream-management bugs. The stated response is to switch that codec off by default and return to Nghttp for HTTP/2.

That is an implementation-selection repair. It does not require describing HTTP/2 itself as unsafe or assuming that request authorization causes the crash. A codec manages protocol state before and during application request processing. Reverting the selected implementation avoids the reported stream-management failure while preserving the use of HTTP/2 through the other codec.

The bulletin additionally lists a JWT-filter crash involving route-cache clearing with remote JWKs, and a LocalReply crash in the HTTP asynchronous client. Those have their own affected processing paths. Their inclusion in one update does not mean they share the private-address trust mechanism or the access-log validation defect.

Patched software and explicit configuration work together

The September release supplies implementation repairs while retaining a compatibility choice around internal-address trust. The bulletin says the runtime guard is currently false by default in both Envoy and Istio. It anticipates a future default change, but that change has not occurred in the release described here. Administrators adopting the stricter behavior must configure it explicitly and account for the restart requirement.

The resulting operating model is more precise than treating every request from a private network as an internal request. Explicit trust configuration identifies the intended sources, patched processing protects the named crash paths, and validation prevents server-name input from corrupting log representation. Each addresses a different boundary that exists before an application receives an authorized request.