Skip to content
Security & Trust

Go update blocks eight certificate keys without saying why

Go 1.27.3 and 1.26.10 reject chains through eight CA keys. Fixing it means rebuilding software, not flipping a switch.

W
WebPulse Newsroom
AI-assisted · 4 min read
Share on X LinkedIn
Go update blocks eight certificate keys without saying why
In brief
  • Go 1.27.3 and 1.26.10 make Go programs reject certificate chains through eight intermediate CA keys. Go cites unspecified security concerns and fixes CVE-2026-111943.
  • Go has no revocation checking, so the block takes effect only when a program is rebuilt on the new release. Teams running Go services need to know where they stand.
  • Ask which services are written in Go, how fast they can be rebuilt, and whether any trust private roots that might now fail.

A trust list that lives inside your software

When a website proves its identity, a program checks a chain of certificates. The chain runs from the site, through an intermediate authority, to a trusted root. Someone has to decide which links are acceptable. For many Go programs, that decision now arrives as a software release.

Go shipped two patch releases on October 20, numbered 1.27.3 and 1.26.10. The commit behind them is titled "crypto/x509: distrust a handful of intermediates" and fixes CVE-2026-111943. It removes any chain that passes through certain intermediates, which it identifies by SHA-256 hashes of their public keys.

The Hacker News reports that the filter covers eight keys. According to the outlet, Go ties all eight to a single certificate authority but does not name it. Go's stated reason is "specific security concerns around their operation." The outlet adds that Go ran the fix through its highest-severity release process and advises upgrading without delay.

How the block works

The Go commit hashes each certificate's public key, not the certificate itself. The Hacker News draws out the effect. Any other certificate that reuses a blocked key is rejected too, even when a different root signed it.

The filter runs inside Go's own verifier. The outlet says the same check also applies on Mac and Windows, where Go hands verification to the operating system. A rejected chain returns the error "x509: no valid chains built."

The Hacker News says the change offers no setting to turn the filter off. It adds that, judging by how the code is structured, the filter seems to apply even when a program supplies its own trusted roots. A private deployment that deliberately trusts one of the eight keys would then fail. Go has not clarified whether that outcome is deliberate.

Why a rebuild is the only route

Go's own documentation says its verifier "doesn't do any revocation checking," The Hacker News notes. Go also ignores the block lists that browsers rely on, including Chrome's CRLSets.

So the only way to block a key is to ship it in a release. Programs keep the old behavior until someone rebuilds them. The outlet says Bluesky's indigo project was among those rebuilt on the new releases the same day.

The lesson here is about who carries the work. A browser vendor can push a block list to every user. A Go service gets the same protection only when its owner rebuilds and redeploys. It resembles a recall notice that helps only the owners who bring the car in.

What nobody has explained

Go's change lists hashes only. A person commenting on the Go issue looked the eight hashes up in certificate records, The Hacker News says, and linked each to an eMudhra intermediate. In that reading, six are TLS intermediates beneath the emSign Root TLS CA - G3 root. The other two are code-signing certificates beneath emSign Root CS CA - G3. The outlet did not verify the match itself.

Firefox's own blocklist, OneCRL, also changed recently. On October 17, Mozilla added six intermediates issued under the emSign Root TLS CA - G3 root. The Hacker News says the Mozilla bug behind that entry is closed to the public. Neither organisation has explained its reason. Whether Chrome, Apple or Microsoft have acted is not established.

Unlike its October 8 security releases, this one came with no advance warning. Go's security policy reserves its top urgency tier for threats to the ecosystem's integrity, or for flaws being exploited with severe damage. Go has not said which of these applied. One user asked the team to explain "who and what they correspond to." As of October 20, there was no reply.

What to ask your team this week

First, ask which of your services, and your vendors' services, are written in Go. Some teams will struggle to answer quickly. Second, ask how long a rebuild and redeploy takes, and who approves it.

Third, ask whether any service deliberately trusts private or unusual roots. Those are the cases The Hacker News says may now fail. Test the new release in staging first, and watch logs for "x509: no valid chains built."

Fourth, have engineers check your certificate chains against the published hashes rather than rely on the unverified matching to eMudhra. Finally, watch for explanations from Go and Mozilla.

A block that cannot be pushed is only as fast as your slowest rebuild.

Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: The Go team (golang/go project, Google).

CVEs in this analysis
CVE-2026-111943
Share this insight