By Go 1.26.5 landed on July 7 with two security fixes. One quietly undermines a privacy guarantee many developers assumed was working: if your Go service has Encrypted Client Hello configured, a passive observer on the network could still identify which server your client was connecting to. The other allows a trailing slash in a file path to break out of a sandboxed directory. Neither requires code changes to fix. Both require updating your toolchain today.
CVE-2026-42505: The ECH Privacy Leak
Encrypted Client Hello (ECH) exists for one reason: to hide the Server Name Indication (SNI) from network observers. Without ECH, anyone watching your TLS handshake can see which domain you’re connecting to in plaintext. ECH encrypts the real ClientHello and sends a sanitized outer version instead, keeping the actual server name private.
Except Go wasn’t fully sanitizing that outer ClientHello. When a session was resuming, the marshalMsg routine included the pre-shared key (PSK) extension in the outer message — the unencrypted one that goes over the wire. PSK identities are tied to specific session contexts, and a passive observer with enough handshakes can use them to correlate which server a client is targeting. ECH was leaking exactly what it was supposed to hide.
The fix omits the PSK extension from the outer ClientHello when ECH is active. It shipped as CL 775960. To check if you’re affected, look for EncryptedClientHelloConfigList in your tls.Config. If you’ve never set that field, this CVE doesn’t change your exposure — though you were already leaking SNI the normal way.
CVSS 5.3 (Medium). No active exploitation reported. But “medium” understates the real-world risk: anyone who deployed ECH specifically to protect user privacy was doing so incorrectly from Go 1.26.0 through 1.26.4.
CVE-2026-39822: One Trailing Slash, One Sandbox Escape
Go’s os.Root API is designed to confine file operations to a directory tree. It’s the Go-native way to implement sandboxed file access — something container runtimes, build tools, and file servers rely on when processing untrusted paths.
There’s a subtle Unix behavior that tripped it up. When you call openat(fd, path, O_NOFOLLOW) and path ends with a trailing slash, the kernel follows symlinks anyway — the O_NOFOLLOW flag is effectively ignored. os.Root didn’t account for this. A call like root.Open("symlink/") would follow a symlink pointing outside the root, escaping the sandbox entirely.
Every function in the os.Root family is affected: OpenInRoot, Root.Create, Root.Open, Root.OpenFile, Root.OpenRoot, Root.ReadFile, and Root.WriteFile. If your code accepts user-supplied paths and passes them through os.Root, untrusted input with a trailing slash could read or write files outside your intended sandbox. Details are in the Go vulnerability database.
How to Upgrade
For most projects using Go module toolchain directives:
go get go@1.26.5
go mod tidyTo download and install the toolchain directly:
go install golang.org/dl/go1.26.5@latest
go1.26.5 download
go version # verify: go1.26.5 linux/amd64If you’re on Go 1.25.x, the parallel fix is Go 1.25.12. Both are available now on the Go downloads page.
Also: golang.org/x/crypto v0.52.0
Go released golang.org/x/crypto v0.52.0 on the same day, patching seven CVEs in the ssh, ssh/agent, and ssh/knownhosts packages. These include server-side panics from crafted bytes (CVE-2026-46598, CVE-2026-46597), silently dropped certificate restrictions from PartialSuccessError (CVE-2026-39834), and revoked CA keys not being checked (CVE-2026-42508).
If your project uses golang.org/x/crypto for SSH server or agent functionality, this is a separate but equally urgent update:
go get golang.org/x/crypto@v0.52.0The full advisory is in the golang-announce thread.
The Bottom Line
Two different standard library guarantees failed in the same release cycle: ECH didn’t protect what it advertised, and os.Root didn’t confine what it should have. Both fixes are in Go 1.26.5. Neither needs a single line of code changed on your end. Run the upgrade, verify with go version, and move on. The only reason to hold off is if you’re on a release with a freeze — and if that’s your situation, you likely have bigger process problems than these two CVEs.
