If you run a VPS, the eMudhra intermediate CA compromise (CVE-2026-111943) is a case where the fix is not a single package you update and forget. Eight intermediate Certificate Authorities issued by eMudhra had their private keys compromised, and the fallout is spread across several independent layers: the Go runtime, Docker Engine, your system ca-certificates store, and the command-line clients that read them. Each vendor shipped a fix on its own schedule, so a fully patched box is one where every check below comes back clean. This article walks the client side of that audit: what was compromised, which version each tool needs, and the exact commands to confirm your machine is no longer trusting the affected chains.[1][2][3]

What was actually compromised

On 17 October 2026 a security researcher reported that the private keys of eight eMudhra intermediate CA certificates were recoverable - the keys weak enough that they could be reproduced from the public certificates in under a second.[4][5] eMudhra revoked all eight on 18 October with the reason caCompromise, and the cross-signing CA revoked its copies on 19 October.[5][6] Because anyone holding such a key could in principle issue certificates for any domain, the affected chains had to be purged from trust everywhere they had been relied on. The eight compromised intermediates are:[2][3]

  • EM DV TLS CA - G3B and EM DV TLS CA - G3C (domain-validated TLS)
  • EM OV TLS CA - G3B and EM OV TLS CA - G3C (organization-validated TLS)
  • EM EV TLS CA - G3B and EM EV TLS CA - G3C (extended-validation TLS)
  • EM OV CS CA - G3B and EM OV CS CA - G3C (code signing)

The G3B intermediates belong to eMudhra BV, the G3C ones to eMudhra Inc. The keys were generated during an April 2025 key-generation ceremony, and the affected roots include emSign Root TLS CA - G3, emSign ECC Root CA - G3 and the cross-signed Comodo AAA Certificate Services path.[3][6]

The practical damage surface is anything that trusts these intermediates. Browsers and OSes that push real-time blocklists (Chrome’s CRLSets, Firefox’s OneCRL) were updated quickly and mostly self-healed. But command-line tooling and software that ships its own certificate bundle - notably everything built on Go’s crypto/x509 - only stops trusting the compromised keys after a software update,[4] which is precisely the gap this article is about.

Why this is tripped up by your toolchain version

The key quirk of this incident is that Go implements its own X.509 chain verification in the standard library instead of deferring entirely to the system’s dynamic libraries.[4] So the fix for Go-based software is not a new root bundle in /etc/ssl; it is a new Go runtime that carries a hard-coded denylist of these specific intermediates. The Go team added exactly that: crypto/x509 now filters out any chain containing the subject public key info (SPKI) of the eight compromised certificates and returns an error from Verify.[1][7]

That resolves the problem for anything linked against a fixed Go version, but it means you have two overlapping mechanisms to track:

  • The Go runtime version for everything compiled with Go (Docker Engine, Terraform, Prometheus, Kubernetes tooling, and any Go binary you build yourself) - fixed in Go 1.26.10 and Go 1.27.3.[1][7][8]
  • The system trust store (/etc/ssl/certs, package ca-certificates) for everything that reads OS roots - fixed by distribution updates, from Ubuntu, Red Hat and others.[9][10][11]

A box can be patched on one axis and still broken on the other. The checks below cover both.

Check 1: your system trust store

Start with the layer most clients read regardless of their own crypto: the OS-level bundle. Where your distro ships the fixed ca-certificates, the affected roots were removed directly from the store, so a certificate chain that relied on one of them is no longer trusted.[9][11]

Ubuntu. Ubuntu’s security team published fixed ca-certificates versions that remove the emSign Root TLS CA - G3 and Comodo AAA Certificate Services roots from the trusted store. The same advisory also fixes the NSS library (libnss3), which carries its own copy of the store, so update both packages in one command. Check what you have installed, then update if it is older:[9]

apt-cache policy ca-certificates
sudo apt update && sudo apt install --only-upgrade ca-certificates 'libnss3*'

Ubuntu’s supported releases all carry a fix as of these versions: Jammy (22.04) 20260816ubuntu0.22.04.1, Noble (24.04) 20260816ubuntu0.24.04.1, Resolute (26.04) 20260816ubuntu0.26.04.1 and Stonking (26.10) 20260816ubuntu0.26.10.1.[9]

Red Hat / RHEL. Red Hat tracks this as RHSB-2026-012. Their bulletin is explicit that every currently-supported RHEL major (6 through 10) shipped the compromised certificates in the trust store via ca-certificates, and that the package is derived from the Mozilla store. Check the installed version, then update when the fixed package is available:[10]

rpm -q ca-certificates
sudo dnf update ca-certificates

Debian. For the system store, pull the ca-certificates update through apt on the same command. (Debian’s tracker entry for CVE-2026-111943 resolves the Golang packages; the store update flows the usual way.)[7]

This check alone is not enough, though - the Go runtime denylist is what actually protects Go-based clients, and that is independent of /etc/ssl.

Check 2: the Go runtime on the host and in your binaries

If you run or build anything in Go - and a dev-grade VPS usually does, whether that is Docker Engine, a deployment tool or an app server - the trust decision happens inside crypto/x509, using a denylist baked into the runtime, not the OS bundle. The fixed versions are Go 1.26.10 and Go 1.27.3.[1][7][8] Check the toolchain you actually use:

go version
go version /usr/local/bin/some-go-binary

The second form prints the Go version a compiled binary was built with, which is a fast way to spot a stale Go-based tool you may have forgotten about: if it reports anything older than 1.26.10 (or 1.27.3), that binary will happily continue trusting the compromised intermediates on its next HTTPS call. Rebuild or refresh any such binary before relying on it.

Check 3: Docker Engine and your registry pulls

Docker Engine is the highest-profile Go-based casualty here. Release 29.9.2 (20 October 2026) carries Go 1.26.10 and is the first Engine that rejects certificate chains containing any of the eight compromised intermediates.[2][3] Before 29.9.2, the Engine would still accept a chain that crossed the affected eMudhra intermediates, so an attacker holding one of the keys could in principle intercept a docker pull or docker push against an affected registry. That risk is what the release closes.

Verify your Engine version:[2][3]

docker version --format '{{.Server.Version}} {{.Server.Os}}/{{.Server.Arch}}'
docker version --format '{{.Client.Version}}'

Both the server (the dockerd daemon) and the CLI should be 29.9.2 or newer. The image pull / image push operations fail TLS certificate verification if a registry’s chain relies on one of the affected intermediates - that is the intended security behavior, not a bug,[2] so a clean pull from a normal registry is exactly what you want. (This is the client/registry side; for the daemon behavior on pull and push under 29.9.2, the Engine change log and the Docker release notes are the authoritative detail.[2][12])

Check 4: curl and command-line HTTP clients

curl is a read-the-OS-bundle client, so it is governed by Check 1 - but it is worth testing explicitly because curl is what a lot of automation and health checks run silently. Two things matter on top of the store update:

  • curl’s own CA bundle. Projects that bundle their own CA file shipped updated bundles (the curl CA bundle update is dated 20 October 2026).[4] If your build or HOMEBREW_CURL_CA_BUNDLE style override points at a fixed cert.pem that still contains the old roots, the store update on the host will not help.
  • A live end-to-end test. The community maintains test endpoints that serve a leaf chained to each compromised intermediate. Pointing curl at one should produce a certificate error if your client no longer trusts the chain:[4]
curl -v https://dv-g3b-emudhra.we-have-a-problem.com/

A certificate verification error here means your curl and store correctly reject the compromised chain. This endpoint is a community-provided check, not a vendor source, so treat the result as a quick sanity signal rather than the definition of the fix - the version checks above are the real gate.

Check 5: git over HTTPS

Git over HTTPS uses the transport’s TLS trust, which on Linux means the system store (again, Check 1) - Git itself does not ship its own CA bundle. So the concrete actions are:

  1. Update ca-certificates (Check 1) so GIT_SSL_VERIFY checks against a store that no longer trusts the affected roots.
  2. If you rely on any opaque middlebox or proxy that terminates TLS with a chain that crossed an eMudhra intermediate, replace that chain rather than disabling verification.

The macOS special case is worth a warning: Apple’s command-line tools, including the git and curl it ships, verify against /etc/ssl/cert.pem without consulting Apple’s revocation lists, and community reports flag that the developer tools shipped with macOS were still trusting the compromised certificates even after system-level revocation took effect.[4] If you administer macOS-based build machines, do not assume the store update happened - test the endpoint from Check 4 explicitly.

The order that actually closes the hole

Because the fix is split across a runtime denylist and a system store, a box is only patched when all of the following are true:

  1. ca-certificates is the fixed version for your distro, so non-Go clients stop trusting the affected roots.
  2. Your Go toolchain is 1.26.10 / 1.27.3 or newer, so Go-built tools reject the compromised intermediates at the runtime level.
  3. Docker Engine server and CLI are 29.9.2 or newer, so registry pulls and pushes enforce the rejection.
  4. curl’s own bundle (where overridden) is the 20 October 2026 bundle or newer.
  5. A live test against a compromised chain produces a certificate error, not a successful connection.

Run the version checks, apply the updates, rerun them, and confirm the test endpoint now fails. Only then is a machine on the client side of this incident actually clear - updating one layer while another still trusts the compromised keys leaves exactly the gap this CVE was built to exploit.

Sources

  1. Golang - issue 82345, “crypto/x509: mitigation for security concerns with a specific Certificate Authority” (CVE-2026-111943; denylist added to crypto/x509; Go 1.26.10 and 1.27.3 fix; backports #82348 for 1.26 and #82349 for 1.27). https://go.dev/issue/82345 - checked 2026-11-02
  2. Docker Engine - version 29 release notes, section 29.9.2 (2026-10-20; Go runtime update to 1.26.10 rejects chains with the eight revoked eMudhra intermediates; image pulls and pushes fail TLS verification on affected chains; lists all eight intermediates and the G3B/G3C vendor split). https://docs.docker.com/engine/release-notes/29/ - checked 2026-11-02
  3. moby/moby - release v29.9.2 (2026-10-20; same security text: Go 1.26.10, eight eMudhra intermediates blocked, packaging update references). https://github.com/moby/moby/releases/tag/docker-v29.9.2 - checked 2026-11-02
  4. Talos Intelligence - “Compromised eMudhra intermediate certificates” (secondary analysis of the compromise and the client-side fix surface; curl/CA-bundle timing; community test endpoints; macOS developer-tools caveat; NOT a primary fact source for the CVE itself). https://blog.talosintelligence.com/compromised-intermediate-certificates - checked 2026-11-02
  5. Mozilla Bugzilla - bug 2083449, “eMudhra: Private key compromise of Intermediate Certificates” (researcher report on 17 October 2026; eMudhra revoked the eight certificates with reason caCompromise on 18 October 2026; timeline of CRLSets revocation). https://bugzilla.mozilla.org/show_bug.cgi?id=2083449 - checked 2026-11-02
  6. AWS Security Bulletin 2026-150 - “CVE-2026-111943: eMudhra intermediate CA key recovery in AWS trust bundles” (eight intermediate keys recoverable due to small-integer scalars; six TLS and two code-signing intermediates; issuing CA revoked 18 October, cross-signing CA revoked 19 October; affected roots listed). https://aws.amazon.com/security/security-bulletins/2026-150-aws/ - checked 2026-11-02
  7. Debian Security Tracker - CVE-2026-111943 (golang-1.26 fixed at 1.26.10-1, golang-1.27 fixed at 1.27.3-1; golang-1.19/1.24 in trixie unresolved no-dsa minor). https://security-tracker.debian.org/tracker/CVE-2026-111943 - checked 2026-11-02
  8. Ubuntu - CVE-2026-111943 security tracker (golang package status across Noble/Jammy/Resolute; cross-references go.dev issue 82345). https://ubuntu.com/security/CVE-2026-111943 - checked 2026-11-02
  9. Ubuntu blog - “eMudhra CA compromise fixes available” (ca-certificates removed the emSign Root TLS CA - G3 and Comodo AAA Certificate Services roots from the trusted store; the same advisory fixes libnss3, which carries its own store; per-release fixed versions: Jammy 20260816ubuntu0.22.04.1, Noble 20260816ubuntu0.24.04.1, Resolute 20260816ubuntu0.26.04.1, Stonking 20260816ubuntu0.26.10.1; update commands). https://ubuntu.com/blog/emudhra-ca-compromise-fixes-available - checked 2026-11-02
  10. Red Hat - RHSB-2026-012, “Certificate compromise - eMudhra (CVE-2026-111943)” (ca-certificates package derived from the Mozilla store; RHEL 6-10 carried the compromised certs; rpm -q ca-certificates check; update when available). https://access.redhat.com/security/vulnerabilities/RHSB-2026-012 - checked 2026-11-02
  11. Google Cloud - GKE security bulletin for CVE-2026-111943 (goes through Ubuntu node ca-certificates and Go runtime patches; external TLS from containerd and control-plane rely on system or Go root stores; internal mTLS unaffected). https://docs.cloud.google.com/kubernetes-engine/security-bulletins - checked 2026-11-02
  12. Docker Engine - version 29 release notes, section 29.9.1 (daemon-side containerd fixes and the release lineage referenced by 29.9.2). https://docs.docker.com/engine/release-notes/29/ - checked 2026-11-02