GPU VulnDB

Database/Container, Kubernetes & orchestration

Envoy: embedded null byte in an OTHERNAME SAN can satisfy match_typed_subject_alt_names

CVSS 7.1CVE-2025-66220Container, Kubernetes & orchestrationcurated

Impact

Envoy's mTLS matcher may treat a certificate whose OTHERNAME SAN value contains an embedded null byte as matching the configured name, so a client or upstream holding a certificate with a crafted SAN passes an identity check it should fail. Where match_typed_subject_alt_names is the authorization rule for a service mesh sidecar or an ingress - the common pattern in front of inference endpoints and internal cluster APIs - this is peer-identity spoofing: a workload with a certificate from an accepted CA can impersonate a different SPIFFE identity and reach services its own identity is not allowed to call. Affected versions are 1.33.12, 1.34.10, 1.35.6, 1.36.2 and earlier. The attacker still needs a certificate the proxy will chain-validate, which is what keeps this at 7.1 rather than higher.

Who can reach it

A network peer that already holds a certificate Envoy accepts as chain-valid - in a mesh, any workload issued a cert by the mesh CA - and can control its SAN contents. Authentication at low privilege required (PR:L); reachable wherever the Envoy listener is.

What to do

Upgrade Envoy past 1.33.12 / 1.34.10 / 1.35.6 / 1.36.2 per the GHSA advisory and restart the proxies; in a mesh this is a sidecar image bump and a rolling restart of the affected workloads, with no GPU node drain. The record does not name the fixed patch releases - take them from GHSA-rwjg-c3h2-f57p. As a stopgap, tighten authorization so identity checks do not rest solely on OTHERNAME SAN matching, and restrict which CAs the listener trusts.

References

Related entries

All Container, Kubernetes & orchestration entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.