Go blocks certificates from eight compromised eMudhra intermediates

Go issued an emergency fix for CVE-2026-111943: the runtime now rejects any certificate chain that passes through a group of eight intermediates with compromised keys, linked to the eMudhra certificate authority.

Editor's note: this article originally described Brad Fitzpatrick as 'one of Go's creators.' That is incorrect: the language's creators are Robert Griesemer, Rob Pike, and Ken Thompson. Fitzpatrick is a long-standing, heavyweight contributor to the Go team, responsible for the version 1.27.3 bump commit cited in the text, but not one of the original creators. We're keeping the rest of the content, which was verified and confirmed against the source issue.

Go issued an emergency fix for CVE-2026-111943: the runtime now rejects any certificate chain that passes through a group of eight intermediates with compromised keys, linked to the eMudhra certificate authority.

Go issued an emergency fix for CVE-2026-111943: the runtime now rejects any certificate chain that passes through a group of eight intermediates with compromised keys, linked to the eMudhra certificate authority.

The emergency patch

On October 19, 2026, the Go team opened issue golang/go#82345, tagged release-blocker and tied to CVE-2026-111943. Starting with this patch, the crypto/x509 package filters, inside the Verify() function, any certificate chain containing a specific set of eight intermediate certificates. The chain is simply no longer returned to the caller: there's no warning, only rejection.

The release-blocker label was applied to the issue, signaling urgency: the team didn't wait for the normal minor-patch release cycle. On the same day the issue was opened, backports were created for issues #82348 (Go 1.26 branch) and #82349 (Go 1.27 branch), and the original issue text literally recommends upgrading immediately.

Why eight intermediates fell together

The issue doesn't publicly detail the technical reasons for the trust suspension beyond mentioning 'specific security concerns about the operation' of the intermediates. Filippo Valsorda, a historic reference figure in Go's cryptography work, provided context directly in the issue's comments:

This is not a policy decision based on how well the CA writes their CPS, the keys are compromised and their certificates revoked.

Filippo Valsorda, a reference figure in cryptography for the Go project

He explains why the fix had to be hardcoded directly into the library. On Linux, he says, root certificate stores are 'a pile of PEM files behind a dumpster': there's no reliable mechanism to propagate an intermediate's revocation to the applications that consume it. Hardcoding the block into crypto/x509 was, in the team's view, the only practical way to ensure Go applications actually stop trusting these chains.

Which CA is behind the block

The public issue doesn't name the certificate authority, but commits that went up across dozens of Go-dependent repositories hours later let the name slip. A commit from developer phinze describes the update as made "for the eMudhra intermediate CA distrust," pointing to eMudhra as the CA whose intermediates had their trust revoked.

Which versions already include the fix

• Go 1.26.10 received the distrust backport (branch for issue #82348, CL https://go.dev/cl/851145).
• Go 1.27.3 received the same backport (branch for issue #82349, CL https://go.dev/cl/851165).
• Go 1.28, still under development, ships with the mitigation applied from the start, since it's the issue's original milestone (CL https://go.dev/cl/851047).

In practice, any Go version prior to these doesn't have the block. You can check the installed version with go version, and the toolchain used by a specific project by looking at the toolchain field in go.mod.

The same fix reached Node.js

The trust problem with these intermediates isn't exclusive to the Go ecosystem. Hours after the original patch, a commit attributed to the automated nodejs-github-bot account appeared in the project's repository with the same stated intent: "tls: reject chains containing blocked public keys." The JavaScript runtime ported the same blocking logic into its own tls module, confirming that any stack relying on the same intermediate certificates is exposed to the same risk, regardless of language.

The controversy: trust filtering inside the standard library

Not everyone agreed with the approach. The issue's most-reacted-to comment, from a user identified as Drugoy, questions whether this kind of decision belongs in a language's standard library:

IMO, this sets a bad precedent. Such extra filtering isn't a job for a programming language's standard package / lib. The library should trust no less than the system does, unless it is initially designed to have its own truststore, like Java does.

Drugoy, comment on the GitHub issue

The comment received 24 agree reactions and 3 disagree reactions, among them one from Daniel McCarney, who reacted against the criticism, that is, in favor of the Go team's decision. Valsorda acknowledged the tension: he said the team will invest in 'less ad-hoc solutions' in the future, but that this requires large-scale ecosystem coordination and won't happen quickly.

What to do now in production

If your Go service makes outbound HTTPS calls, runs a reverse proxy, or terminates TLS in Go, the risk is concrete: if the certificate on the other end of the connection was issued by one of the now-blocked intermediates, verification will start failing as soon as you update the runtime, with an x509 certificate chain error.

1. Update your Go toolchain to 1.26.10, 1.27.3, or the latest version available, both locally and in your CI/CD pipeline.
2. After updating, run integration tests against all the external HTTPS endpoints your service consumes, not just your own certificates.
3. If any handshake starts failing, use openssl s_client -connect host:443 -showcerts to inspect the chain and identify the issuer of the suspect intermediate.
4. For certificates issued to your own company via eMudhra, contact the CA or certificate provider for reissuance through an unaffected chain.

It's worth noting that several major projects had already updated Go on the same day as the patch, including bumps signed by Brad Fitzpatrick and commits across dozens of dependent repositories scattered throughout the ecosystem. The volume of updates on the first day is an indication of how seriously the ecosystem took the warning.

Source 1: Hacker News (https://github.com/golang/go/issues/82345)

crypto/x509: mitigation for security concerns with a specific Certificate Authority · Issue #82345 · golang/go · GitHub

Skip to content

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

Dismiss alert

crypto/x509: mitigation for security concerns with a specific Certificate Authority #82345 New issue Copy link New issue Copy link Closed Closed crypto/x509: mitigation for security concerns with a specific Certificate Authority #82345 Copy link Labels Security release-blocker Milestone Go1.28 Description thatnealpatel opened on Oct 19, 2026 Issue body actions We're blocking trust in a small set of intermediate certificates due to specific security concerns around their operation.

Verify will now filter out chains which contain these intermediates, preventing them from being returned to the caller.

We highly recommend immediately upgrading to this release.

This is CVE-2026-111943 and Go issue https://go.dev/issue/82345 .

This was an URGENT track issue originally tracked in http://b/575512169 . Reactions are currently unavailable Activity Next thatnealpatel added this to the Go1.28 milestone on Oct 19, 2026 thatnealpatel added Security release-blocker on Oct 19, 2026

thatnealpatel commented on Oct 19, 2026 thatnealpatel on Oct 19, 2026 Last edited by dmitshur Member Author More actions @gopherbot Please open backports for this issue.

gopherbot commented on Oct 19, 2026 gopherbot on Oct 19, 2026 Contributor More actions Backport issue(s) opened: #82348 (for 1.26), #82349 (for 1.27).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases . 👍 React with 👍 1 Reacted by AriESQ gopherbot added 2 commits that reference this issue on Oct 20, 2026 [release-branch.go1.26] crypto/x509: distrust a handful of intermediates ... aa64342 [release-branch.go1.27] crypto/x509: distrust a handful of intermediates ... 90617fb

gopherbot commented on Oct 20, 2026 gopherbot on Oct 20, 2026 Contributor More actions Change https://go.dev/cl/851165 mentions this issue: [release-branch.go1.27] crypto/x509: distrust a handful of intermediates

gopherbot commented on Oct 20, 2026 gopherbot on Oct 20, 2026 Contributor More actions Change https://go.dev/cl/851145 mentions this issue: [release-branch.go1.26] crypto/x509: distrust a handful of intermediates

gopherbot commented on Oct 20, 2026 gopherbot on Oct 20, 2026 Contributor More actions Change https://go.dev/cl/851047 mentions this issue: crypto/x509: distrust a handful of intermediates thatnealpatel changed the title [-] security: fix CVE-2026-111943 [/-] [+] crypto/x509: mitigation for security concerns with a specific Certificate Authority [/+] on Oct 20, 2026 gopherbot added a commit that references this issue on Oct 20, 2026 crypto/x509: distrust a handful of intermediates ... 7f86f95 thatnealpatel closed this as completed on Oct 20, 2026 chenxiaolong added 2 commits that reference this issue on Oct 20, 2026 external/go: Update to go1.27.3 ... 0e623cf external/go: Update to go1.27.3 ... 06bfbc8

14 remaining items Load more sluongng added a commit that references this issue on Oct 20, 2026 deps: upgrade Go to 1.27.3 ( #13875 ) ... 880460c

Drugoy commented on Oct 20, 2026 Drugoy on Oct 20, 2026 More actions IMO, this sets a bad precedent. Such extra filtering isn't a job for a programming language's standard package / lib.

The library should trust no less than the system does, unless it is initially designed to have its own truststore, like Java does. 👍 React with 👍 24 Reacted by minullin, deanos2310, Tobias, Raffy E., Ellen Emilia Anna Zscheile, Cirno the Strongest, Jason Healy, makeworld, Brandon Mendrick, Denis and 14 more 👎 React with 👎 3 Reacted by Macy D., Youfu Zhang and Daniel McCarney bradfitz added a commit that references this issue on Oct 20, 2026 go.toolchain.rev: bump to Go 1.27.3 ... b2bbb0b vettid added 5 commits that reference this issue on Oct 20, 2026 Build: golang 1.26.10-alpine by tag and digest (crypto/x509 distrusts… ...

3d7ce03 Build: golang 1.26.10-alpine by tag and digest (crypto/x509 distrusts… ... 4c072c4 Build: golang 1.26.10-alpine by tag and digest (crypto/x509 distrusts… ... 2693249 Build: toolchain go1.26.10 (crypto/x509 distrusts eight intermediates) ( ... a70b98e Build: Go 1.26.10 (crypto/x509 distrusts eight intermediates) ( #133 ) ... a527822 dims added a commit that references this issue on Oct 20, 2026 build: bump Go to 1.27.3 ( #1821 ) ... b386658

FiloSottile commented on Oct 20, 2026 FiloSottile on Oct 20, 2026 Contributor More actions This is not a policy decision based on how well the CA writes their CPS, the keys are compromised and their certificates revoked.

Unfortunately, the state of Linux root stores (a pile of PEM files behind a dumpster) is such that the revocation of these intermediates has no way to propagate to applications, short of hardcoding them in code like this.

The Go cryptography libraries exist to help developers build secure applications . An application that accepts chains through these revoked intermediates is not secure, so we patched the Go cryptography libraries accordingly.

We'll be investing in less ad-hoc solutions for the future, but that requires large-scale ecosystem coordination, so it won't be quick. 👍 React with 👍 6 Reacted by AriESQ, Serge Bazanski, Apoorv Munshi, Khiman Louer, Jack Platten and Kane York nickoneill added a commit that references this issue on Oct 20, 2026 go.toolchain.rev: bump to Go 1.27.3 ( #21870 ) ... 42347eb nodejs-github-bot added a commit that references this issue on Oct 20, 2026 tls: reject chains containing blocked public keys ... d9a3f3d lizthegrey added a commit that references this issue on Oct 20, 2026 maint: bump go to 1.27.3 ...

2373ff0 phinze added a commit that references this issue on Oct 20, 2026 Build with Go 1.27.3 for the eMudhra intermediate CA distrust ... a08d3b4 maint: bump go to 1.27.3 ... 6c44005 Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment Metadata Assignees No one assigned Labels Security release-blocker Type No type Projects No projects Milestone Go1.28 No due date Relationships None yet Development No branches or pull requests Issue actions

Open in GitHub Copilot app

You can't perform that action at this time.