Istio fixes inconsistent handling of repeated HTTP headers

An HTTP header name can have more than one value in the parsed message. A security check that reads only the first value can then operate on a different effective input from another component. Replacing only the first occurrence creates a related problem, because additional values can remain after a filter believes it has overwritten the header. Istio's September security update addresses both behaviors in Envoy.

The September 29 advisory assigns CVE-2020-25017 a CVSS score of 8.3. It lists Istio 1.6 through 1.6.10 and 1.7 through 1.7.2 as affected. The recommended updates are 1.6.11 and 1.7.3. The 1.7.3 release notice confirms that the release carries the security correction.

I consider consistent interpretation of request data a necessary part of moving security policy into a proxy. A policy can express the intended header condition correctly while the implementation supplies it an incomplete value. The behavior of the header map therefore matters to the security properties of the configuration built on top of it.

Matching must account for the complete value set

The Envoy v1.15.1 release notes, dated September 29, describe the correction in more detail. Previously, matching did not consider every occurrence of non-inline headers. The patch changes the default to logically concatenate repeated values with a comma, making matching consistent with inline header behavior.

This is a change to the input supplied to the matcher. It does not mean every repeated value independently satisfies a configured exact match. A combined value is a different string from one individual value. Rules consuming the result need to be understood against the representation the implementation actually provides.

For example, consider a synthetic list-valued field carried as two header lines. This is a representation example, not a published exploit against a particular Istio policy.

X-Example-Values: alpha
X-Example-Values: beta

The important distinction is between examining only alpha and examining the logical combination containing both values. A consumer that sees only the first has lost information present in the message. The patch makes the additional value participate in the matching operation instead of remaining outside that operation's view.

The example does not establish that arbitrary header names are allowed to repeat under HTTP's semantics. Repetition has restrictions according to the field definition. The security implementation still needs predictable handling of the values it receives, including inputs chosen by an untrusted sender.

HTTP already defines conditions for combination

RFC 7230 section 3.2.2, published in June 2014, discusses repeated fields. A sender is not supposed to generate multiple fields with the same name unless the field's value uses a comma-separated list or it is a recognized exception. For fields that can be combined, recipients may append values in order with commas without changing their semantics.

The RFC also says the order of repeated values matters and must not be changed by a forwarding proxy. It identifies Set-Cookie as an exception that cannot be combined like an ordinary list field. These distinctions show why HTTP header handling cannot be reduced to a dictionary that silently keeps one value for every name.

The same section requires receiving the whole header section before applying a request to the target resource. Its explanation includes the possibility that later fields contain credentials or misleading duplicates. That is the protocol-level reason an early acceptable value cannot be assumed to describe the whole message. The repeated-value defect concerns a related loss of information after parsing, when an operation considers only one occurrence.

That protocol context is useful without overextending the advisory. Envoy's notice identifies matching and mutation of non-inline headers. It does not claim that every header type should be rewritten into a comma-separated list regardless of its semantics. The disclosed fix concerns the operations and extensions named in the release notes.

An engineer reading a policy therefore needs two kinds of information. The field definition determines the meaning of its values. The proxy implementation determines which values the policy operation actually receives. A gap in the latter can undermine the intended use of the former.

Several extensions share the corrected behavior

The Envoy notes name extensions using CEL header matching, the header-to-metadata filter, JWT, and Lua as receiving targeted fixes. Those extensions now consider duplicate values as a comma-concatenated list by default. The primary header matching used in routing and RBAC receives the same general correction.

The affected operations have different purposes. Routing chooses where a request goes, while RBAC participates in access control. Header-to-metadata processing derives information used elsewhere. A header map behavior shared by these consumers can therefore have consequences beyond a single filter configuration.

The list also explains why an application owner may be affected without having written a custom Envoy extension. Built-in processing paths use these operations. The flaw sits below their configured behavior, in how repeated fields become the values the operation examines.

At the same time, the notice does not provide an exploit for every listed consumer. It establishes that their treatment of duplicates changes. Claims about a particular application's access bypass need its actual policy and downstream interpretation. The general correction removes the incomplete first-value view described by the project.

Replacement has to remove the old occurrences

The second part of the fix concerns the setCopy() header map API. Before the patch, it set only the first occurrence when duplicate non-inline headers existed. After the patch, it replaces all matching occurrences with a single value, consistent with the other setter APIs described in the notes.

This is a mutation problem rather than a matching problem. A filter can deliberately set a header to a trusted value, yet leave another occurrence behind if the setter only changes the first. A later consumer may still encounter the remaining value. Replacing every occurrence makes the resulting map agree with the operation's intended whole-header effect.

The Envoy notes specifically identify potential security implications for the external authorization filter, which uses that API. That is the project's stated connection between the setter semantics and a security-relevant consumer. It should not be broadened into a claim about every external authorization arrangement without examining that arrangement.

The distinction also helps explain why fixing reads alone is insufficient. A matcher can consider all values correctly while a setter still leaves stale values in the map. Conversely, a setter can replace everything correctly while another matching path still reads one value. The release addresses both operations because they create different inconsistencies.

Runtime compatibility settings can restore old behavior

The versioned Envoy notes describe runtime switches for the matching and replacement changes. They allow the previous behavior to be restored. That compatibility mechanism is relevant to interpreting a running patched proxy, because the binary's version and the selected runtime behavior are separate facts.

Restoring old behavior also restores the semantics the security correction changes. It should not be described as an equivalent mitigation. The Istio advisory directs users to patched releases, and the Envoy release notes identify the new defaults that make those releases' header operations consistent.

I prefer to assess the result through the actual operation being used. A match should receive the complete logical value set promised by the corrected implementation. A replacement should leave the single intended value instead of retaining additional occurrences. Those are concrete properties that can be reasoned about from the release's documented changes.

The corrected versions belong on the affected request path

The Istio patch versions provide the project-supported remediation for each affected branch. The vulnerability is in Envoy, so the behavior that matters is the proxy actually processing the relevant traffic. A control plane version alone does not describe the implementation inside every proxy in a mesh.

The release notice does not require changing the HTTP field definitions or adopting a new authentication protocol. It repairs implementation consistency underneath existing routing and security features. Application configuration can remain syntactically valid across the update while producing a different result for requests containing repeated headers.

The substantive change is therefore observable in two places. Header matching now incorporates the repeated values that the old non-inline path could omit. Header replacement removes all old occurrences before leaving the new value. Together those changes reduce disagreement between the request a security component evaluates and the header state that other components subsequently consume.