Go crypto/tls EUVD-2026-95422

The target server must have Encrypted Client Hello (ECH) enabled in Go's crypto/tls - an opt-in feature that is not active in default Go TLS server configurations; this is the key limiting factor. Given ECH is configured, a remote client can trigger the flaw with no authentication by sending a single crafted ClientHello during the TLS handshake that specifies multiple ECH outer extension references (prohibited by RFC 9849). Exploitation is further limited to Go server versions prior to 1.27.2 / 1.26.9. No user interaction and no valid credentials are required, but the non-default ECH requirement sharply narrows the real-world attack surface.

No CVSS vector, EPSS score, KEV listing, or POC was provided in the source data, so this assessment is built from the vulnerability description alone (crypto/tls ECH outer extension handling in Go 1.27.2 / 1.26.9). The flaw is a memory-exhaustion / amplification denial-of-service: a client sends a crafted TLS ClientHello specifying multiple ECH (Encrypted Client Hello) outer extension references, which RFC 9849 forbids, and the pre-fix server allocates disproportionate memory. It is triggered during the TLS handshake, before any application authentication, so from a network-reachability standpoint it behaves like an unauthenticated remote condition - but note the input contains no CVSS:PR metric to confirm this per precision rules, so the handshake-timing observation is inferred from the description, not from a provided vector. Impact is confined to availability (no confidentiality or integrity effect is described). The realistic priority is MODERATE and strongly gated by a configuration dependency: the server must have ECH enabled, which is an opt-in/experimental TLS feature not active in default Go server configurations. Absent EPSS/KEV/POC signals and given the ECH gating, this is a genuine-but-conditional DoS rather than a widespread, high-urgency threat - patch on a normal cadence unless ECH is actively deployed, in which case prioritize. Verify ECH exposure with your own TLS configuration audit.

A malicious client opens a TLS handshake against a Go-based server that has Encrypted Client Hello (ECH) enabled and sends a crafted ClientHello that declares multiple ECH outer extension references. The pre-patch crypto/tls code expands these into a disproportionate memory allocation, exhausting memory in the server process and degrading or crashing the service. No public exploit code was identified in the provided data.