CVE-2025-66220: 
Envoy vulnerability analysis and mitigation

CVE-2025-66220 is an mTLS certificate validation bypass vulnerability in Envoy Proxy caused by improper null termination (CWE-170) in the match_typed_subject_alt_names certificate matcher. When a client certificate contains an embedded null byte (\0) inside an OTHERNAME Subject Alternative Name (SAN) value encoded as BMPSTRING or UNIVERSALSTRING, Envoy may incorrectly accept it as a valid match against a legitimate identity. Affected versions include Envoy ≤ 1.33.12, 1.34.0–1.34.10, 1.35.0–1.35.6, and 1.36.0–1.36.2; patched versions are 1.33.13, 1.34.11, 1.35.7, and 1.36.3. The vulnerability was published on December 3, 2025, with a CVSS v3.1 base score of 5.0 (Moderate) per the GitHub Security Advisory (GitHub Advisory, Envoy Advisory).

The root cause is CWE-170 (Improper Null Termination): when Envoy converts a BMPSTRING or UNIVERSALSTRING-encoded OTHERNAME SAN to UTF-8, the resulting string is truncated at the first null byte during string assignment. This means a certificate with SAN value "victim\0evil" will be stored internally as "victim", causing it to match an exact: "victim" rule in match_typed_subject_alt_names and be accepted by Envoy's mTLS enforcement. Exploitation requires the attacker to obtain a CA-trusted client certificate with a crafted null-byte-embedded OTHERNAME SAN — a precondition that limits practical exploitability. A proof-of-concept is publicly documented in the advisory, demonstrating that a client_null certificate with OTHERNAME BMPSTRING "victim\0evil" is accepted while a certificate with "evil" is correctly rejected (Envoy Advisory).

Successful exploitation allows an attacker to impersonate a trusted identity in mTLS-protected environments, bypassing the OTHERNAME SAN exact-match access control enforced by Envoy. This enables unauthorized access to services or APIs that rely on Envoy's certificate-based identity verification, with high confidentiality impact (access to protected data/services) and low integrity impact (potential for unauthorized actions). Availability is not affected, and the scope is unchanged, meaning the impact is confined to the vulnerable Envoy instance and the services it protects (GitHub Advisory).

A proof-of-concept is publicly documented in the Envoy security advisory, demonstrating the bypass with crafted certificates. However, exploitation requires the attacker to already possess a certificate signed by a trusted CA with a specially crafted OTHERNAME SAN — a high-privilege precondition that significantly limits real-world exploitability. There is no evidence of in-the-wild exploitation at this time, and the vulnerability is not listed in the CISA KEV catalog. The EPSS score is approximately 0.002% (0th percentile), reflecting very low near-term exploitation probability (GitHub Advisory, Envoy Advisory).

1. Obtain CA access: Gain the ability to issue certificates from a CA trusted by the target Envoy instance — this is the primary prerequisite and the highest barrier to exploitation.
2. Craft a malicious client certificate: Generate a client certificate with an OTHERNAME SAN encoded as BMPSTRING or UNIVERSALSTRING containing an embedded null byte, e.g., "victim\0evil", where "victim" is the identity authorized by the Envoy match_typed_subject_alt_names rule.
3. Sign the certificate: Have the crafted certificate signed by the trusted CA so it passes Envoy's chain-of-trust validation.
4. Initiate mTLS connection: Present the crafted client certificate to the target Envoy listener configured with require_client_certificate: true and an exact: "victim" OTHERNAME matcher.
5. Bypass access control: Envoy truncates the SAN value at the null byte, matches "victim", and accepts the connection — granting unauthorized access to the protected service or API (Envoy Advisory).

• Network: mTLS connections from client certificates whose OTHERNAME SAN contains binary/non-printable characters or null bytes when decoded; unexpected successful mTLS handshakes from clients not previously authorized.
• Logs: Envoy access logs showing successful TLS connections from certificates with OTHERNAME SAN values that appear truncated or contain unusual encoding (BMPSTRING/UNIVERSALSTRING) when inspected with tools like openssl x509 -text.
• Certificate Inspection: Client certificates presented to Envoy with OTHERNAME SAN values that, when decoded, contain embedded null bytes (\x00) — detectable via openssl asn1parse or similar ASN.1 inspection tools.

Upgrade Envoy to one of the patched versions: 1.33.13, 1.34.11, 1.35.7, or 1.36.3. As an interim measure, review all mTLS configurations using match_typed_subject_alt_names with OTHERNAME OID matchers and implement additional certificate validation at the CA level to reject certificates with non-standard SAN encodings. Restrict the ability to issue certificates from trusted CAs to minimize the attacker's ability to obtain a crafted certificate (Envoy Advisory, GitHub Advisory).

The Istio project published a related security advisory (ISTIO-2025-003) shortly after the Envoy disclosure, indicating downstream impact on Istio service mesh deployments that rely on Envoy as their data plane (Istio Advisory). Red Hat also tracked the vulnerability for their products (Red Hat CVE). Amazon Web Services addressed the issue in their ECS-optimized AMI advisory ALAS2ECS-2025-093, and Microsoft Azure AKS released a patch in their January 4, 2026 release notes, reflecting broad ecosystem attention to the vulnerability.