Istio host authorization depends on the receiving proxy version

A policy can be unchanged while the configuration generated from it changes meaning for an older proxy. That is the failure behind CVE-2022-21679. Istio 1.12.0 and 1.12.1 can generate incorrect host authorization configuration for proxies on 1.11, making a mixed-version upgrade a security-relevant state.

The January 18 advisory identifies authorization rules using hosts or notHosts as affected. The result can be an unintended bypass or an unintended rejection. Istio 1.12.2 corrects the generated configuration, and the advisory also gives avoiding the affected version combination as a mitigation.

I regard workload identity as a sound foundation for a mesh, but identity does not make an authorization policy enforce itself. The control plane has to translate the declared policy into a form the actual proxy understands. This vulnerability occurs at that translation boundary.

The affected state includes both planes

The advisory's affected releases are 1.12.0 and 1.12.1. Its description narrows the relevant deployment state further. Those control planes must be configuring a 1.11 data plane, and the authorization policy must use the host-related fields.

That is an important distinction from saying every Istio host rule is broken. The defect concerns a particular producer and consumer combination. A fleet-level label such as Istio 1.12 conceals whether all proxies have reached the same version as the control plane.

During an upgrade, those versions can differ. The advisory makes that intermediate state part of the applicability condition. The policy text is not sufficient evidence of correct enforcement because the same declaration passes through version-sensitive generation.

The two outcomes also deserve separate attention. A bypass weakens the intended restriction. An unexpected rejection denies traffic that policy should permit. Both indicate a semantic mismatch, but they produce different operational symptoms.

A user reporting rejected requests may therefore be observing the same configuration defect as another deployment experiencing overly permissive behaviour. The advisory does not provide one universal traffic symptom that establishes or excludes applicability.

The fix chooses a host matcher for the proxy

The 1.12.2 authorization generator contains a host generator with a proxy-version condition. Its permission method first rejects use for TCP because host matching is HTTP-specific. For the appropriate newer proxy version it calls one host matcher, and otherwise it calls a regular-expression-based matcher.

That branch is the concrete mechanism behind compatibility. The desired host restriction remains the same, but the representation sent to the proxy differs. A control plane needs to select the representation using the receiving proxy's capabilities.

The matcher implementation in the same release shows what each representation contains. The newer form constructs an Envoy string matcher with case-insensitive matching. Depending on the value, it uses exact, prefix, or suffix matching.

The older-compatible form builds a safe regular expression. It escapes the literal portion of the configured host, supplies the appropriate wildcard part, and prefixes the expression with the case-insensitive marker. A value of * uses a presence matcher.

The two implementations also show why a readable policy diff cannot fully describe an upgrade. The policy may have no diff at all while the control plane selects a different Envoy field. Review of generated configuration needs to account for that representation change.

Those details matter because policy compatibility concerns interpretation, not merely successful delivery of a protobuf message. The generator must express the same intended matching behaviour through a representation supported by the consumer. The source makes the version-dependent choice visible.

The implementation's comments should not replace the advisory's applicability statement. The reported vulnerable combination is a 1.12.0 or 1.12.1 control plane with 1.11 proxies. That is the combination operators need to identify, regardless of broader historical commentary in a helper function.

A host pattern is not an arbitrary regular expression

The matcher code escapes literal text before constructing its regular expression. That preserves host-pattern semantics instead of treating every policy value as free-form regex source. A period in a hostname should retain its literal meaning when represented inside a regex.

For an exact host value, the compatibility path therefore uses an escaped literal with case-insensitive matching. A leading or trailing wildcard changes the generated prefix or suffix treatment. The wildcard's location has a defined role in construction.

This is an example of why configuration translation needs its own correctness analysis. A high-level policy field and a lower-level matcher do not necessarily share the same language. The generator must convert between them without accidentally widening or narrowing the set of accepted requests.

Version differences introduce another dimension to that conversion. Even a correct high-level interpretation can fail if represented through a matcher form that the receiving proxy does not handle as intended. Compatibility is part of the security mechanism because the proxy is where the request decision occurs.

The code supports that explanation without requiring an invented exploit request. Its advisory states the bypass and rejection risk. The tagged source shows the corrected representation choice. Neither establishes an observed compromise in any particular deployment.

Negative host rules need the same care

The advisory includes notHosts alongside hosts. That is relevant because a matcher defect can affect both positive and negative conditions. The operational consequence depends on how a rule combines those conditions with the rest of its authorization policy.

It would be unsafe to reason that a negative match is less important because it describes an exclusion. An exclusion can define the sensitive part of a rule. If the generated matcher does not preserve the intended set, the complement of that set will also be wrong.

The same caution applies to interpreting an unexpected rejection as evidence that enforcement is conservative. A rule that rejects one allowed request may still mishandle other request classes. One observed denial does not establish that the overall policy is stricter in every case.

The useful unit of analysis is the intended request set and the actual generated matcher. That includes the receiving proxy version. A declaration stored in Kubernetes is the policy input, while the proxy's configuration is the executable representation of that input.

The patch fixes generation without rewriting the policy model

The 1.12.2 release notes confirm the security fix on January 18. They describe the same affected host fields and older proxy combination. The release also addresses a separate privilege-escalation vulnerability, which is a different issue with its own applicability conditions.

For this host-rule advisory, the prescribed correction is to upgrade to 1.12.2. The alternative mitigation is to avoid mixing the affected control planes with 1.11 proxies when using the fields in question. The advisory does not prescribe deleting host restrictions or weakening the authorization policy.

That distinction preserves the security requirement while changing the faulty implementation path. Replacing a policy with a broader one would alter the intended access decision. Correcting generation aims to restore the policy's original meaning.

My preference is to treat the control-plane and proxy version pair as part of an authorization configuration's operating context. A source-controlled rule can be stable while its compiled representation changes during an upgrade. The declared rule and its runtime consumer need to be understood together.

Why the upgrade interval matters

A mesh's control plane and data plane do not form one indivisible executable. This advisory shows the consequence through a concrete generation branch. Updating the producer changes the code that emits configuration before every consumer necessarily changes.

That interval deserves explicit description in upgrade documentation. An account that only names the starting version and final version omits a state in which production enforcement may run. Here the vulnerable state is exactly the mixed combination between those endpoints.

The fix also illustrates a responsibility of control planes that support older proxies. They must generate configuration compatible with each supported consumer. A newer representation cannot be selected solely because the control plane itself contains the corresponding code.

For operators assessing this advisory, the needed facts are bounded. Identify the control-plane version, the proxy versions it configures, and policies using the affected host fields. Where the stated combination exists, 1.12.2 supplies the corrected generation path. That connects the security action to the component that produces the faulty configuration while retaining the intended authorization rules.