CVE-2025-66220 Overview
CVE-2025-66220 affects Envoy, a high-performance edge, middle, and service proxy widely deployed in service mesh and API gateway architectures. The vulnerability resides in Envoy's mutual TLS (mTLS) certificate matcher logic for match_typed_subject_alt_names. The matcher incorrectly treats certificates containing an embedded null byte (\0) inside an OTHERNAME Subject Alternative Name (SAN) value as valid matches. An attacker holding a certificate with a crafted OTHERNAME SAN can bypass identity-based authorization checks. The flaw is tracked under CWE-170: Improper Null Termination.
Critical Impact
Authenticated attackers can bypass mTLS identity matching and impersonate trusted services in Envoy-fronted environments.
Affected Products
- Envoy 1.33.x through 1.33.12
- Envoy 1.34.x through 1.34.10
- Envoy 1.35.x through 1.35.6 and 1.36.x through 1.36.2
Discovery Timeline
- 2025-12-03 - CVE-2025-66220 published to NVD
- 2025-12-05 - Last updated in NVD database
Technical Details for CVE-2025-66220
Vulnerability Analysis
Envoy uses match_typed_subject_alt_names to validate peer certificates against an allowlist of expected SAN values during mTLS handshakes. The matcher compares the decoded OTHERNAME SAN value against configured matchers using string comparison routines that terminate on null bytes. When a certificate presents an OTHERNAME SAN containing an embedded \0, the matcher truncates comparison at the null byte. A certificate with a SAN value such as trusted.service\0attacker.example is treated as matching trusted.service. This allows an attacker with a validly signed certificate from a permitted certificate authority to impersonate identities the matcher was configured to permit.
Root Cause
The root cause is improper null termination handling [CWE-170] in the SAN matching code path. ASN.1 OTHERNAME values are length-prefixed octet strings and may legitimately contain null bytes, but Envoy's comparator treated them as C-style strings. The mismatch between the certificate encoding semantics and the comparison routine produces incorrect equality results.
Attack Vector
Exploitation requires the attacker to obtain a certificate signed by a CA trusted by the target Envoy deployment, with attacker-controlled content in the OTHERNAME SAN field. The attacker presents this certificate during the mTLS handshake to an Envoy listener configured with match_typed_subject_alt_names. Envoy accepts the connection and applies the policy associated with the spoofed identity, granting access to upstream services intended only for the legitimate identity holder.
No verified public proof-of-concept code is available. See the Envoy GitHub Security Advisory GHSA-rwjg-c3h2-f57p for vendor technical details.
Detection Methods for CVE-2025-66220
Indicators of Compromise
- Peer certificates presented to Envoy listeners that contain embedded null bytes within OTHERNAME SAN values.
- Access logs showing successful mTLS connections from client identities that do not match expected service principals.
- Unexpected upstream cluster access from workloads whose SPIFFE IDs or service identities deviate from documented baselines.
Detection Strategies
- Parse Envoy access logs and audit the DOWNSTREAM_PEER_URI_SAN and DOWNSTREAM_PEER_SUBJECT fields for non-printable characters or null bytes.
- Inspect issued certificates at the certificate authority for OTHERNAME SAN values containing 0x00 bytes.
- Correlate authentication telemetry from sidecars and ingress proxies to identify identity mismatches between TLS peer SANs and application-layer identifiers.
Monitoring Recommendations
- Enable verbose TLS handshake logging on Envoy listeners using match_typed_subject_alt_names and forward logs to a centralized analytics platform.
- Alert on any certificate issuance events that include control characters in SAN fields.
- Monitor for service-to-service traffic patterns that violate established zero-trust policy baselines.
How to Mitigate CVE-2025-66220
Immediate Actions Required
- Upgrade Envoy to a fixed release: 1.33.13, 1.34.11, 1.35.7, 1.36.3, or later as published in the vendor advisory.
- Audit all certificate authorities trusted by Envoy listeners and restrict issuance templates to forbid null bytes in SAN extensions.
- Review match_typed_subject_alt_names configuration and confirm matchers reflect the minimum required identity set.
Patch Information
The Envoy maintainers released fixed versions following the disclosure documented in GHSA-rwjg-c3h2-f57p. Operators running Envoy 1.33.12, 1.34.10, 1.35.6, 1.36.2, or earlier must upgrade. Service mesh distributions that embed Envoy, including Istio and Envoy Gateway, should be updated once downstream releases incorporate the fix.
Workarounds
- Replace match_typed_subject_alt_names with exact-match URI SAN validation that rejects values containing non-printable bytes via custom validation filters.
- Enforce SPIFFE identity validation at the application layer in addition to Envoy-level matching until patched binaries are deployed.
- Restrict trusted CAs in Envoy validation_context to the smallest possible set to reduce the surface for forged OTHERNAME SANs.
# Verify Envoy version on a running proxy
envoy --version
# Example: upgrade Envoy container image to a patched tag
docker pull envoyproxy/envoy:v1.36.3
kubectl set image deployment/envoy envoy=envoyproxy/envoy:v1.36.3
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
