MEDIUM 4.4

CVE-2026-47778: Envoy Proxy Certificate SAN Validation Bypass (NUL Byte)

Envoy proxy versions before 1.35.11, 1.36.7, 1.37.3, and 1.38.1 contain a certificate validation bypass vulnerability. An attacker can craft a certificate with a malicious DNS Subject Alternative Name (SAN) containing a hidden NUL byte character. Due to improper string handling in the validation logic, Envoy truncates the certificate's SAN at the NUL byte and compares only the truncated portion against expected values, allowing an invalid certificate to pass validation. This could enable a sophisticated attacker with certificate-issuance capability to impersonate legitimate upstream services in Envoy-routed environments.

Source data · NVD / CISA · public domain

CVSS
3.1 · 4.4 MEDIUM · CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N
Weaknesses (CWE)
CWE-158
Affected products
1 configuration(s)
Published / Modified
2026-06-26 / 2026-06-29

NVD description (verbatim)

Envoy is an open source edge and service proxy designed for cloud-native applications. Prior to 1.35.11, 1.36.7, 1.37.3, and 1.38.1, a structural flaw was identified in DefaultCertValidator::verifySubjectAltName where the extracted DNS SAN string is cast to a C-style string using .c_str() before being passed to the Utility::dnsNameMatch() algorithm. If the attacker serves a certificate with a dNSName SAN containing an embedded NUL byte, the helper Utility::generalNameAsString captures the complete string including the NUL. However, when .c_str() evaluates it, implicit conversion to absl::string_view inside dnsNameMatch relies on strlen(), prematurely truncating the evaluation context. Envoy evaluates trucated string against the exact required config_san match and returns true, thereby successfully validating the string with the Nul byte for an upstream routing. This vulnerability is fixed in 1.35.11, 1.36.7, 1.37.3, and 1.38.1.

2 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

The vulnerability resides in Envoy's DefaultCertValidator::verifySubjectAltName function. The flaw occurs in a two-stage string processing error: first, Utility::generalNameAsString correctly captures the full dNSName SAN including any embedded NUL bytes into an std::string; second, when this string is converted via .c_str() and passed to Utility::dnsNameMatch for validation against the configured upstream SAN requirement, the function internally converts the C-style pointer to absl::string_view. The string_view constructor calls strlen() on the pointer, which stops at the first NUL byte, effectively truncating the validation context. If the attacker's certificate contains a SAN like 'attacker.com\x00legitimate.com', only 'attacker.com' is evaluated against the config_san match. If 'attacker.com' matches a valid upstream alias, validation succeeds despite the certificate being invalid for the actual upstream domain.

Business impact

Organizations deploying Envoy as an edge proxy or service mesh control point face a certificate validation bypass that could allow traffic interception or service impersonation. An attacker capable of obtaining a certificate for attacker-controlled or compromised domains could potentially route traffic intended for legitimate upstreams through malicious endpoints, leading to data theft, session hijacking, or man-in-the-middle attacks. The impact is constrained by the requirement that the attacker must obtain or control a valid certificate, but the vulnerability effectively nullifies Envoy's SAN pinning and strict upstream verification controls.

Affected systems

Envoy proxy deployments running versions 1.35.0–1.35.10, 1.36.0–1.36.6, 1.37.0–1.37.2, and 1.38.0 are vulnerable. Organizations should verify their exact Envoy version and patch status immediately. This affects Envoy when configured with strict upstream certificate validation (particularly common in service mesh and zero-trust architectures where SAN pinning is enforced).

Exploitability

Exploitation requires two conditions: (1) the attacker must obtain a valid TLS certificate (for any domain they control or can compromise), and (2) that certificate's dNSName SAN must be crafted with an embedded NUL byte and an additional payload after it that matches a legitimate upstream SAN in the target environment's Envoy config. The attack is not trivial but is feasible for sophisticated threat actors or insiders with certificate-issuing capabilities. CVSS 4.4 (Medium) reflects the high access requirements (privileged attacker context) and conditional triggering, though the impact when successful is confidentiality-critical.

Remediation

Upgrade affected Envoy instances to patched versions: 1.35.11 or later, 1.36.7 or later, 1.37.3 or later, or 1.38.1 or later. No workaround exists short of upgrading. Organizations should prioritize patching in environments where Envoy enforces upstream certificate pinning or SAN validation as a primary security control.

Patch guidance

Apply the following patches based on your current version: upgrade from 1.35.x to 1.35.11+, from 1.36.x to 1.36.7+, from 1.37.x to 1.37.3+, or from 1.38.0 to 1.38.1+. Verify patch application by confirming the new version in Envoy's admin interface or log output. Test patched deployments in a staging environment to confirm upstream service connectivity remains stable before production rollout.

Detection guidance

Monitor for certificates presented to Envoy with SAN values containing embedded NUL bytes (0x00). Review upstream certificate logs and Envoy's certificate validation audit events for any unexpected SAN values or validation results. Intrusion detection systems can flag TLS handshakes where certificate SAN contains NUL bytes. Additionally, audit Envoy configuration files to identify which upstreams enforce SAN pinning—these are the highest-risk targets for this vulnerability.

Why prioritize this

Despite the medium CVSS score, this vulnerability warrants prompt attention because it directly undermines certificate-based authentication in service-to-service communication. In zero-trust and service mesh deployments, certificate validation is often the last line of defense; bypass of this control can lead to lateral movement and data exfiltration. Prioritize patches for Envoy instances handling sensitive inter-service or edge traffic.

Risk score, explained

CVE-2026-47778 scores 4.4 MEDIUM under CVSS 3.1 (AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N). The score reflects network accessibility but high attack complexity and high privilege requirements (the attacker must obtain a valid certificate and knowledge of upstream SAN configuration). Confidentiality impact is high because successful exploitation enables traffic interception. Integrity and availability impact are rated none because the attack does not modify upstream responses or disrupt service. The relatively low score should not diminish urgency in environments where SAN validation is a critical control.

Frequently asked questions

Can an attacker exploit this without a valid TLS certificate?

No. The vulnerability requires the attacker to present a valid, signed TLS certificate containing a crafted SAN with an embedded NUL byte. This means the attacker must either control a trusted certificate authority, compromise one, or obtain a certificate for a domain they control or have compromised.

Does this affect all Envoy deployments or only those with specific configurations?

The vulnerability exists in all affected versions, but exploitation is most likely in environments where Envoy is configured to enforce upstream certificate SAN pinning or exact SAN matching. Deployments that accept any valid certificate from a trusted CA without SAN constraints have lower practical risk, though the underlying flaw remains present.

What is the difference between this vulnerability and standard SAN validation bypasses?

Most SAN bypasses exploit weak wildcard matching or case-sensitivity issues. This vulnerability exploits a C-string handling bug where strlen() truncates the validation string at a NUL byte, effectively allowing the attacker to hide the real certificate domain behind a benign-looking truncated string. It is a memory-safety class bug rather than a logic error.

If we patch Envoy, do we need to revoke any upstream certificates?

Patching Envoy is sufficient; upstream certificates do not need to be revoked. However, if you suspect that malicious certificates with NUL-byte SANs were presented to your Envoy instances before patching, review logs and investigate potential compromises.

This analysis is based on vendor advisory data and CVE public record. Organizations should verify patch availability and compatibility with their Envoy deployment before applying updates. No exploit code or proof-of-concept is provided. For official vendor guidance, consult the Envoy security advisory and your deployment documentation. Source: NVD (public-domain), retrieved 2026-08-05. Analysis generated by SEC.co (claude-haiku-4-5).