Envoy Proxy CVE-2026-47778

Exploitation requires that the attacker be in a network position to serve a TLS certificate to Envoy acting as a TLS client connecting to an upstream - either by directly controlling the upstream server or by executing a man-in-the-middle attack on the Envoy-to-upstream network segment. The targeted upstream connection must be subject to SAN-based certificate validation with a configured config_san match in Envoy; upstreams without SAN validation enabled are not affected by this specific flaw. The attacker must additionally be able to obtain or forge an X.509 certificate with an embedded NUL byte in the dNSName SAN field, which in practice requires either control of a certificate authority, use of a CA that does not sanitize SAN content, or presentation of self-signed certificates in deployments that do not strictly enforce upstream CA trust. Exploitation is bounded by: (1) the need to control or MITM an upstream TLS endpoint (AC:H), (2) the requirement to produce a valid X.509 certificate containing a NUL-embedded dNSName SAN, and (3) the targeted Envoy deployment must use SAN-based validation for the specific upstream in question. Deployments relying solely on Subject CN matching, or those where upstreams use strictly-managed internal CAs with proper SAN content validation, are less exposed. The CVSS vector is PR:H per the vendor, though the advisory does not explicitly require privileges on the Envoy instance itself.

The vendor-provided CVSS 3.1 vector AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N yields a score of 4.4, reflecting high attack complexity and a high privilege prerequisite. The C:H rating is well-grounded - successful SAN bypass enables Envoy to route traffic through or accept connections from an attacker-controlled upstream, directly exposing proxied application traffic. The AC:H rating is similarly justified by the need to control an upstream endpoint or execute a network-level MITM attack. The PR:H component is the most debatable metric: controlling an external upstream server does not require privileges on the Envoy instance itself, and the vendor's PR:H appears to reflect the operational positioning difficulty rather than classical privilege escalation. This interpretation is not independently confirmed by the advisory text. No EPSS score was provided in source data, and the vulnerability is not listed in CISA KEV. With no public exploit, AC:H, and the operational requirement to control or MITM an upstream TLS session, real-world exploitation risk is moderate-to-low for most deployments - but environments where upstream certificate authorities are weakly controlled or where upstream network paths are exposed to semi-trusted parties face meaningfully elevated risk.

An attacker who controls or can perform a man-in-the-middle attack against an upstream server that Envoy routes traffic to crafts a TLS certificate with a dNSName SAN of 'trusted.example.com\x00.attacker.com' and presents it during the TLS handshake. Envoy's verifySubjectAltName extracts the full SAN string but the subsequent .c_str() call causes strlen()-based truncation inside dnsNameMatch, reducing the evaluated string to 'trusted.example.com', which matches the operator-configured config_san. Validation returns true, Envoy routes proxied application traffic through the attacker's endpoint, and sensitive data is exposed. No public proof-of-concept code has been identified at time of analysis.