On October 20, the Go team released Go 1.27.3 and Go 1.26.10, which added a deny list to crypto/x509 to block eight intermediate Certificate Authority (CA) keys. The release carried an urgent security fix, with the maintainers only citing “specific security concerns around their operation,” but the issue was handled on its URGENT track, which its security policy reserves for its most serious issues. This drew some of the earliest public attention to the issue, as developers and the press tried to work out what exactly was happening.
Google’s Chrome Root Program explained that the keys belong to eMudhra intermediate CAs and their private keys were generated with insufficient randomness (weak cryptographic entropy), which allows anyone to forge trusted HTTPS certificates and impersonate any website against clients that still trust those CAs. Browsers blocked the keys within hours of the first report on October 17, and Apple and Microsoft followed on October 19 and 20. Software that relies on outdated or custom trust stores, including language runtimes, package managers, containers, and command-line tools, stays exposed until it is updated. Go is an example of this: it doesn’t check revocation, so its fix only takes effect once an application is rebuilt and redeployed with the secure versions.
What is Happening
On October 17, a security researcher, who goes by “Wayne”, reported to the browser root programs that the private keys of eight eMudhra intermediate CA certificates had been compromised. As proof, the researcher signed a message with each of the eight keys.
Chrome’s Root Program received the report at 18:05 UTC, and, by 19:45 UTC, the issue was confirmed and the keys’ public key hashes blocked through its CRLset, protecting Chrome users without a browser update.
Firefox followed within hours, with Mozilla adding six TLS intermediates issued under eMudhra’s emSign Root TLS CA – G3 to OneCRL, the list Firefox uses to block certificates.
Additionally, both Google and Mozilla removed emSign ECC Root CA – G3 from their own trust stores. This means that certificates chaining to this root will cease to work for anyone relying on these trust stores.
eMudhra reportedly revoked the eight certificates on October 18. On October 19, Mozilla began disclosing the issue to downstream trust-store operators. Apple devices began blocking the intermediates, and Android received an equivalent block through Google Play Services. Microsoft platforms followed on October 20. Various maintainers also began shipping updates, including Python’s certifi, curl’s CA bundle, Alpine Linux’s ca-certificates package, and Cloudflare’s CFSSL trust store, with Ubuntu, Debian, and others publishing patched versions as well.
On October 20, the issue became public with Google’s Chrome Root Program and Mozilla publishing their explanations, and Go releasing versions 1.27.3 and 1.26.10 tracked as CVE-2026-111943.
The flaw was in the original key generation, not in the cryptographic signatures themselves. A P-384 private key should be uniformly selected from a space of roughly 2384 possible values. All eight affected keys used integers below 256, which means each private key was effectively all zeroes except the last byte. That leaves only a few hundred possible keys. They can be recovered almost immediately with the baby-step giant-step discrete logarithm algorithm, or more simply by generating the first 256 P-384 keys and checking which ones match the public key in the certificate. In practice, anyone could recompute the private key from the public certificate, allowing anyone to forge trusted HTTPS certificates to impersonate any website against clients that have not yet removed trust in those CAs.
eMudhra has acknowledged the incident. According to the company, the issue is limited to eight intermediates created during a key generation ceremony in April 2025, and its root CA private keys and other intermediates are unaffected. During the key generation ceremony, a flaw caused a wrap/unwrap step to produce a second, weak set of keys alongside the intended strong ones. The weak set was the one published to the browser root stores.
The company also says only one of the eight was deployed in production, and none issued an end-entity certificate. Google found no TLS certificates chaining to the six TLS intermediates in Certificate Transparency (CT) logs, which protected CT-enforcing browsers. Many other clients, including many developer tools and servers, don’t enforce CT, and it isn’t known whether any were targeted.
Why Go is Different, and Why It Isn’t Alone
Go makes the problem easy to see. It does not check revocation or consume browser blocklists, so a block must come inside a new release. The impact that follows from that is:
- Existing binaries stay exposed. Until an application is rebuilt on a patched release, it remains vulnerable to certificates forged with these keys.
- After a rebuild, matching chain fails with x509: no valid chains built.
- The filter matches the keys themselves, so cross-signed copies of the same keys are caught too.
- There is no setting to turn it off. It likely also applies to private deployments that supply their own trusted roots, so an internal setup that intentionally trusts one of these keys would fail too.
- Go 1.25 and older receive no fix. The only route is a supported release.
But Go wasn’t the only part of the software supply chain that had to react. Python’s certifi and Rust’s webpki-roots dropped the compromised root from their bundles, and pip, iv, and Electron shipped patched releases. Operating systems such as Ubuntu and Debian, and container base images also carry their own trust lists that need updating. Besides this, the fix is not standard: Go blocks the eight keys, while others remove the whole root CA, which cuts off legitimate certificates beneath it. Each layer has its own trust store and update cycle.
This incident is a reminder that supply chain security is more than protecting code and its deployment. Your application, the packages it depends on, the container it runs in, and the operating system underneath all rely on a certain layer of trust that can be compromised. A compromised CA must be removed from every dependent, and if one still trusts it, forged certificates can still get through.
What About Apple and Microsoft?
Browsers weren’t the only ones to act. According to the incident site run by Mozilla’s Dennis Jackson, Apple has blocked the compromised intermediates since October 19, and Microsoft since October 20. These intermediates chain to roots trusted by the Mozilla, Chrome, Microsoft, and Apple root programs, so they had to be blocked individually to allow other trusted intermediates from the same root to work normally.
However, blocking these intermediates does not protect everywhere, though:
- Apple: the block covers Safari and apps that use the system’s own certificate checks. The built-in `/usr/bin/curl` checks certificates against `/etc/ssl/cert.pem` without checking revocation, and that file has not been updated.
- Microsoft: reports found Edge on Windows 10 still connecting to test hosts on October 20. The block is delivered through Windows’s automatic root certificate updates, so if this feature is disabled, like in locked-down or offline environments, they may not receive these updates.
- Cross-signed copies: Sectigo, one of the biggest certificate authorities (CAs), cross-signed the eight intermediates, so clients can build chains through those paths as well. That’s why the effective fix is to block the keys themselves, as the browsers and Go did.
- Code Signing: two of the eight are code-signing intermediates, trusted in Microsoft’s root store. This means that software signed under them could look legitimate to tools that don’t check revocation.
At the time of writing, neither Apple nor Microsoft had published their own advisory on the incident.
What Should I Do?
Confirm that nothing in your environment connects to, relies on, or uses certificates chaining through the eight eMudhra intermediates. eMudhra says none of them issued an end-entity certificate, so legitimate use is unlikely, but a forged certificate would look valid to any client that still trusts the chain. Do this for all software that uses its own trust store, since a browser update doesn’t cover it.
Currently, this seems to be the most comprehensive all-in-one public coverage website we found:
https://emudhra.we-have-a-problem.com/
The site was published by Dennis Jackson of Mozilla, who worked on Mozilla’s response to the report from “Wayne,” the researcher who originally found the issue. It covers:
- Proof of compromise: signatures made with each of the eight keys, verifiable with OpenSSL.
- A client check: test hosts that show whether your browser, curl, or another client still trusts the compromised intermediates. A certificate error means it doesn’t.
- Machine-readable lists of the eight intermediates, their Sectigo cross-signs, and the roots they chain to.
- A table of patched versions for operating systems, runtimes, and packages, including Go, Python certifi, pip, and the curl CA bundle.
- Workarounds for macOS curl and several Linux distributions.
In this case, no single resource can map out everything that was affected. We recommend you apply broader security controls and investigate the most appropriate measures to mitigate your particular situation. Internally, we are taking various measures to secure our own products and customers.
Conclusion
This issue goes to show how a CA’s intermediate keys being compromised can affect various ecosystems and entire supply chains. Browsers were protected within hours: Chrome blocked the compromised intermediates through its CRLSet, protecting users without a browser update or restart, and Mozilla pushed a block through OneCRL to standard Firefox installs, followed by packaged updates for the rest. Apple blocked the intermediates on October 19 and Microsoft on October 20.
Go and others shipped their own fixes around the same time, and those required software updates and infrastructure checks to make sure nothing broke. Whole supply chains were affected, and the lesson is that supply chain security must cover not only code and its deployment but also any trust layer that every component relies on.
Vulnerabilities