Skip to content
Hacker Posts

Go blocks eight CA keys in emergency 1.27.3/1.26.10 update

Go 1.27.3 and 1.26.10 hard-block eight intermediate CA keys over undisclosed 'security concerns.' Chains through them now fail with x509: no valid chains built. Rebuild.

Published 3 min read
advisorygolangpkitls

Go shipped 1.27.3 and 1.26.10 on October 20 on its URGENT track, hard-blocking eight intermediate CA keys in the standard library's X.509 verifier over unspecified "security concerns around their operation." Programs built with the new releases reject any certificate chain through those keys with x509: no valid chains built. The filter cannot be disabled, and it applies even to private roots that intentionally trust one of the keys.

The primary source is the Go team's security release announcement and the change (commit 7f86f957633ee31a1c17a1eb8452ca7a3d9bc141), which identifies the keys only by SHA-256 hash. The Hacker News walked through the details.

What's affected

  • Releases: Go 1.27.3 and 1.26.10 carry the block. Go 1.25 and older are out of support and get no fix.
  • Behavior: Chains validating through the eight keys fail closed. Older binaries keep the old behavior until rebuilt with a patched toolchain, so the change propagates as you recompile — not retroactively.
  • Scope: The block is in crypto/x509, so it reaches anything that uses Go's verifier — Go services doing TLS, and tools built in Go that validate certificates.

Which CA?

Go has not named the CA. A commenter matched all eight hashes to eMudhra intermediates; The Hacker News notes it has not independently verified the hashes. On that matching, the blocked keys are eMudhra's G3B/G3C intermediates for DV, OV and EV TLS plus OV code-signing:

EM DV TLS CA - G3B / G3C
EM OV TLS CA - G3B / G3C
EM EV TLS CA - G3B / G3C
EM OV CS CA - G3B / G3C   (code signing)

Treat the eMudhra attribution as community matching, not an official statement. What is confirmed: Mozilla added six eMudhra intermediates to its OneCRL revocation list on October 17, two days before Go's release. Neither Go nor Mozilla has said publicly what prompted the action.

Exploitation status

None stated. Go's URGENT track is reserved for threats to ecosystem integrity or actively exploited flaws, and the team did not say which applied — nor did it pre-announce this release, unlike its October 8 security batch. The underlying events are not public.

Action checklist

  1. Rebuild Go services and Go-based tooling with 1.27.3 or 1.26.10; the block only takes effect once binaries are recompiled.
  2. Inventory certificates in your chains that terminate in eMudhra G3B/G3C intermediates (public endpoints, internal PKI that cross-signs, code-signing pipelines). Anything chaining through them will fail once rebuilt.
  3. If you find affected certificates, reissue from a different CA ahead of the rebuild rather than after an outage.
  4. If you run a private root that deliberately trusts one of these keys, note the filter overrides it — plan a migration, as there is no opt-out flag.

Context

A toolchain hard-blocking a CA with no public rationale is unusual, and it fits a wider run of CA-trust actions this year across browser and language ecosystems. When a root program (Mozilla's OneCRL) and a language runtime (Go) move within 48 hours and neither explains why, the quiet part is doing the talking — operators should migrate off the affected intermediates now rather than wait for the postmortem.

Related stories