Istio's December fixes protect identity parsing and protocol transitions
Embedded nulls could defeat a typed certificate SAN match, while JWKS re-entry could crash Envoy. CONNECT early-data protection also requires attention to an explicit runtime setting.
A certificate can pass cryptographic validation while an application misinterprets the identity encoded inside it. That is the important boundary in Istio's December certificate-matching advisory. The flaw concerns conversion of a particular subject alternative name into a string and its subsequent comparison, rather than an ability to forge the issuing authority's signature.
The December 3 Istio advisory covers CVE-2025-66220 in typed SAN matching, CVE-2025-64527 in remote JWKS fetching and CVE-2025-64763 in early CONNECT data handling. It lists affected releases as 1.28.0, 1.27.0 through 1.27.3, and 1.26.0 through 1.26.6. The conditions for each issue are different.
I consider identity attached to workloads the central justification for a mesh. That makes correct identity parsing part of the security mechanism itself. Establishing mutual TLS does not help if the value used for a subsequent identity decision differs from the value actually present in the trusted certificate.
The matcher accepted a truncated identity
The upstream certificate advisory identifies match_typed_subject_alt_names and an OTHERNAME SAN value. When the value is encoded as BMPSTRING or UNIVERSALSTRING, conversion to UTF-8 can produce a string containing an embedded null. Assignment then truncates that result at the first null byte.
The advisory illustrates the mismatch with a value containing the sequence victim, a null byte and evil. An exact rule for victim can accept the resulting truncated string even though the certificate's value includes additional content. The comparison has lost information that should distinguish the two identities.
This failure requires more than a client sending an arbitrary text field. An attacker needs a certificate trusted by the verifier with the relevant OTHERNAME content, a prerequisite explicitly included upstream. The issue does not establish that an unsigned or untrusted certificate becomes trusted merely by including a null byte.
The exact-match policy also matters. The advisory's reproduction configures a specific OTHERNAME object identifier and requires a client certificate. Ordinary rejection of a missing certificate still works in that example. A trusted certificate carrying a different nonmatching name is also rejected. The specially encoded value instead passes the identity match it should fail.
That is why the defect belongs to authorization-relevant interpretation after trust has been established. A chain can be valid under the configured authority while its identity fails the intended policy. Both checks need to be correct for the resulting access decision to represent the administrator's rule.
Typed SANs are a configuration-specific exposure
Istio's advisory calls out custom certificates with OTHERNAME SANs. It does not state that every ordinary Istio workload certificate has this representation or that every mesh policy uses the affected matcher. The relevant inventory combines the certificate type with the proxy's configured identity comparison.
The upstream fix is included in Envoy 1.36.3, 1.35.7, 1.34.11 and 1.33.13. Those version numbers identify the proxy implementation. The corresponding Istio patch is the appropriate distribution-level artifact for an Istio installation.
The mechanism also explains why changing an exact rule to the visible prefix would not be a repair. That prefix is already what the vulnerable conversion mistakenly produces. The implementation needs to retain the full identity value or reject an invalid representation, so that comparison cannot silently discard a suffix.
The conversion detail narrows the root cause further. The certificate contains a typed ASN.1 value, while the matcher operates on a converted string. Correctness requires preserving the length and content across that representation change. A terminator-based assignment can interpret an embedded byte as the end of the value even when the original representation has additional content. The signature authenticates the encoded certificate, so it does not detect that a later consumer discarded part of an authenticated field. This explains why ordinary chain validation and rejection of an obviously different name can both pass their own checks while the special case still defeats the exact-match rule. The defect appears in the relationship between those otherwise meaningful checks.
I find the prerequisite more useful than a broad statement that TLS is broken. The affected deployment trusts an authority capable of issuing the certificate and relies on a particular typed name check. That is a narrower boundary, and it is the boundary the patch needs to preserve.
Remote JWKS fetching fails through re-entry
The CVE-2025-64527 record documents a different issue. Envoy must use remote JWKS fetching with allow_missing_or_failed enabled, the request must carry multiple JWT tokens in headers, and fetching the key set must fail. These conditions combine to reach a re-entry bug in JwksFetcherImpl.
When the first token's fetch fails, the error callback starts processing the second token. That can call fetch again on the same object. The original callback then resets the object and clears state belonging to the second fetch, including its receiver and request references.
The later asynchronous HTTP response arrives after that state has been cleared and triggers a crash. This is a lifetime problem across callbacks. The first operation's cleanup is no longer confined to the first operation because the object has already started another one.
The allow_missing_or_failed setting is therefore not enough to make a failure harmless. It governs the intended authentication behavior when validation is unavailable or fails. The implementation still needs to handle the transition safely. A policy that permits processing to continue cannot compensate for cleanup that invalidates the next asynchronous request.
Istio specifically identifies custom JWT authentication with remote JWKS fetching through EnvoyFilter as an exposure. The upstream conditions are more detailed and explain why the failure is not a claim about every RequestAuthentication or every JWT-bearing request. The configured filter and the failed fetch path determine whether this bug can be exercised.
Early CONNECT data can desynchronize intermediaries
The CVE-2025-64763 record concerns Envoy in TCP proxy mode handling CONNECT requests. Envoy can accept client data before returning a successful 2xx response and forward it into the upstream TCP connection.
If another forwarding proxy upstream rejects establishment of the tunnel with a non-2xx response, the participants can disagree about tunnel state. Data has already moved through a transition that an intermediary did not accept. The record describes this as a desynchronized CONNECT tunnel state, which is the basis of the request-smuggling concern.
The important detail is the order of data and acknowledgment. Ordinary application data inside an established tunnel has different meaning from bytes sent while the tunnel request is still awaiting approval. Forwarding those bytes early assumes that the transition will succeed across the relevant intermediaries.
Istio's advisory warns users accepting WebSocket traffic that they may be exposed. The upstream description supplies the more specific CONNECT and forwarding-proxy conditions. Those should be used together, without turning the warning into a claim that every WebSocket request independently smuggles another request.
The CONNECT protection is an explicit choice
The upstream record says Envoy continues to permit early CONNECT data by default to preserve compatibility. It adds envoy.reloadable_features.reject_early_connect_data as a setting that rejects CONNECT requests sending data before a 2xx response. This is particularly relevant where upstream intermediaries can reject tunnel establishment.
That qualification changes the meaning of patching. The updated implementation provides a control, but the record does not say the stricter rejection becomes the default. An installation that needs that protection must account for the runtime setting as well as the patched executable.
This is different from the certificate and JWKS fixes, whose documented problem is incorrect parsing or invalid callback state. CONNECT early data also has compatibility implications for existing clients. Rejecting it changes accepted behavior, which explains why the upstream response includes an explicit configuration decision.
The Istio 1.28.1 announcement confirms that the release implements the December advisory. It also contains separate fixes for ambient service scope and endpoint caching. Those repairs should not be mistaken for the cause of the three security findings, even though the same patch delivers them.
For certificate matching, the relevant outcome is that a trusted certificate with the wrong complete identity cannot satisfy the exact typed-SAN rule. A failed first JWKS fetch must not invalidate another fetch started during its callback. CONNECT needs a deliberate early-data policy consistent with the installation's intermediaries. Those are the distinct security properties represented by the December update.