Istio fixes regex interpretation of service-account identities

A service account named cert-manager.io is a literal identity. In an affected Istio authorization matcher, the dot became a regular-expression wildcard. The April 20 security bulletin describes the resulting authorization bypass as CVE-2026-39350. The policy author selected one account, but the generated matcher could accept names with a different character in place of the dot.

This is particularly relevant to why I use Istio. After five years with it, I still regard workload identity as the right basis for access policy. That approach only works when the implementation preserves the identity named in configuration. A correct certificate and a correctly authenticated caller do not repair an authorization matcher that recognizes a larger set of identities than the policy author specified.

The bulletin also covers CVE-2026-41413, a server-side request forgery problem involving RequestAuthentication.jwksUri. Both issues concern configuration crossing into another interpreter. One turns an identity string into a regular expression. The other turns a policy URL into a network request made with the control plane's reachability. Their patches belong to different mechanisms even though operators receive them in the same update.

Literal identity strings entered a regex template

The service-account advisory identifies both serviceAccounts and notServiceAccounts fields. Its example shows cert-manager.io matching alternatives such as cert-manager-io and cert-managerXio. A dot is valid in the account name, so the problem does not require a malformed policy value. Ordinary valid input exposed the missing quoting step.

The implementation patch makes the transformation visible. The generator constructs a SPIFFE identity expression containing namespace and service-account components. Corrected code passes those inserted components through regexp.QuoteMeta. That preserves their literal meaning within the larger expression while retaining the regex structure used for the identity format.

The patch's tests make the intended distinction concrete. A policy input containing a dotted account must still match the corresponding dotted identity. Replacing the dot with an arbitrary character must fail. The tests also cover the generated expression itself, which now contains an escaped dot in the inserted account component.

The relevant difference can be expressed as an illustrative matcher fragment:

Unquoted account component: cert-manager.io
Quoted account component:   cert-manager\.io

This is a fragment explaining the correction, not a configuration change to paste into AuthorizationPolicy. Policy values remain account names. Escaping belongs to the code generating a regex, because that code knows which characters are literal data and which characters define the surrounding matcher.

Asking users to understand the internal expression would put responsibility in the wrong place. A service-account selector presents an identity-oriented interface. Its implementation must translate that identity without expanding the set of acceptable callers. The patch restores that property at the generation point rather than introducing a new identity notation for users.

Positive and negative policy fields share the interpretation problem

The advisory's inclusion of notServiceAccounts matters. An implementation error in a shared matcher can affect policy logic that includes negation, as well as a straightforward positive allowlist. The resulting decision depends on where the matcher appears in the policy. The reliable conclusion is that the selected identity set is wrong before the surrounding policy evaluates it.

For a positive ALLOW example, accepting a lookalike account clearly grants an unintended caller access. More complex combinations need analysis of their actual rule structure. A broad claim that every policy using these fields has one identical outcome would conceal that dependency. The advisory identifies the affected fields and gives a direct example of the identity expansion.

The published patch also quotes namespace text inserted into the expression. Its tests exercise regex metacharacters in both components. Some test inputs serve to verify the helper's escaping behavior rather than establish which names Kubernetes admits in every resource. That distinction keeps the implementation evidence useful without turning a unit-test string into a claim about valid cluster object names.

The security fix illustrates why certificate identity and policy compilation need separate scrutiny. Authentication can establish the caller's actual identity, and compilation can still produce the wrong decision procedure for the configured target. Both operations are necessary to implement the workload-based access model. This update corrects the second operation.

JWKS URLs caused requests from the control plane

The JWKS request advisory describes istiod making an unauthenticated HTTP GET to the URL named by a RequestAuthentication resource. Without filtering localhost and link-local addresses, the request can reach internal services. The response can then appear in configuration distributed to Envoy through xDS.

The relevant privilege is the ability to cause the resource to be created. The bulletin specifically calls out installations where users or automated systems can create RequestAuthentication objects. Whoever authors that resource influences a request made from istiod's network position. This is a delegation of network activity, even though the immediate user operation looks like declaring authentication policy.

An internal address is significant because of where the request originates. The control plane may reach a service that the policy author cannot contact directly. The vulnerability uses that difference in reachability. A policy URL therefore needs controls over its resolved connection destination, as well as ordinary syntactic validity as a URL.

The advisory describes a partial mitigation in earlier patches that missed some paths. The Istio 1.29.2 release notes, dated April 13, explain the stronger correction. A custom control function in a custom DialContext filters connections after name resolution and before dialing. That placement lets the restriction follow redirects and issuer discovery.

Connection-time filtering covers derived destinations

Checking a policy's initial URL is not equivalent to checking the destination eventually dialed. DNS resolution supplies addresses, and a redirect or discovery request can introduce another destination. The release notes identify those paths as reasons for the revised implementation. The connection-time check applies the restriction after the destination has resolved, before establishing the connection.

The notes also say the implementation preserves default dialing behavior such as happy eyeballs and trying resolved addresses in order. That is a practical design constraint. A security restriction inserted into a custom dialer must still support the legitimate connection behavior expected by the caller. The patch description records both the filtering point and the networking behavior retained around it.

The advisory offers admission policy as a workaround for suspicious jwksUri values, naming localhost and link-local examples. That can restrict what users submit, but it is a different control from the patched connection-time filtering. The robust fix accounts for the network requests derived from the initial configuration, including paths that the earlier mitigation missed.

This is also distinct from March's unsafe JWKS fallback issue. A failed key fetch and an unwanted fetch destination are different failures. The April bulletin concerns where istiod can be induced to send a request and how returned data reaches proxies. A corrected failure response does not by itself prevent a request to an internal address.

An admission restriction can also express a platform rule about who is allowed to choose authentication endpoints. That policy remains useful after patching because it defines intended delegation. The patch and the platform rule answer different questions. The former corrects the unsafe connection path, while the latter limits which callers may ask the control plane to fetch authentication material in the first place.

Patch availability and disclosure have different dates

The April 20 bulletin recommends Istio 1.29.2 or later for the 1.29 line and 1.28.6 or later for the 1.28 line. The service-account advisory also identifies 1.27.9 as patched for that particular issue. For JWKS, the advisory lists 1.29.2 and 1.28.6 for its stronger correction. Those issue-specific lists should remain distinct when assessing an older installation.

The earlier publication date of the 1.29.2 notes means the bulletin is explaining fixes already available in that release. A timeline that treats disclosure as the release date would lose that distinction. As of April 20, operators can use the bulletin to understand why those matcher and dialer changes belong in the security upgrade assessment.

The additional distributed system remains a cost in my view of Istio. These fixes show why its value depends on precise translation between workload policy and implementation. Account names must remain literal when compiled, and a declared authentication URL must not grant arbitrary use of the control plane's network access. The published patches make those corrections in the generator and connection path that enforce the existing configuration model.