Envoy Null Pointer and Configuration Handling Flaws

Identity impersonation in Envoy Proxy (1.33.12 and earlier, 1.34.0-1.34.10, 1.35.0-1.35.6, and 1.36.0-1.36.2) allows a client to be accepted under a different identity when Envoy is configured with require_client_certificate: true and an exact match_typed_subject_alt_names rule against an OTHERNAME SAN. Specifically, a certificate whose OTHERNAME value is encoded as BMPSTRING or UNIVERSALSTRING and carries an embedded null byte (for example 'victim\0evil') is truncated at the null during UTF-8 conversion and therefore matches an exact rule for 'victim', granting the attacker the access rights of that identity. Publicly available exploit code exists and the vendor has released patches, but EPSS is 0.00% and exploitation is gated on the attacker first obtaining a CA-signed certificate from a CA that Envoy trusts, so this is a precondition-heavy issue rather than a mass-exploitable one. Note authentication requirements: the CVSS vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N, indicating the attacker must already hold valid credentials (a trusted client certificate).

Envoy is a high-performance edge/middle/service proxy. In 1.33.12, 1.34.10, 1.35.6, 1.36.2, and earlier, Envoy crashes when JWT authentication is configured with the remote JWKS fetching, allow_missing_or_failed is enabled, multiple JWT tokens are present in the request headers and the JWKS fetch fails. This is caused by a re-entry bug in the JwksFetcherImpl. When the first token's JWKS fetch fails, onJwksError() callback triggers processing of the second token, which calls fetch() again on the same fetcher object. The original callback's reset() then clears the second fetch's state (receiver_ and request_) which causes a crash when the async HTTP response arrives.

Envoy is a high-performance edge/middle/service proxy. In 1.33.12, 1.34.10, 1.35.6, 1.36.2, and earlier, when Envoy is configured in TCP proxy mode to handle CONNECT requests, it accepts client data before issuing a 2xx response and forwards that data to the upstream TCP connection. If a forwarding proxy upstream from Envoy then responds with a non-2xx status, this can cause a de-synchronized CONNECT tunnel state. By default Envoy continues to allow early CONNECT data to avoid disrupting existing deployments. The envoy.reloadable_features.reject_early_connect_data runtime flag can be set to reject CONNECT requests that send data before a 2xx response when intermediaries upstream from Envoy may reject establishment of a CONNECT tunnel.