CVE-2026-111943: Go Blocks Compromised eMudhra CA Keys After Certificate Authority Incident

A major public key infrastructure incident has triggered emergency security measures across browsers, programming language ecosystems, certificate stores, and software packages. Private keys associated with eight eMudhra intermediate certificate authority certificates were compromised, potentially allowing unauthorized parties to create certificates that could appear trustworthy to vulnerable clients.

The incident affects six TLS intermediates used for domain-validated, organization-validated, and extended-validation certificates, along with two code-signing intermediates. Because an intermediate CA can issue certificates below a trusted root, possession of its private key creates a substantially different risk from the compromise of an ordinary website certificate. An attacker could potentially create fraudulent certificates that inherit trust from the affected chain.

The Go Project responded by introducing CVE-2026-111943, which addresses cases where Go applications could continue trusting certificate chains containing the compromised intermediates. Go 1.26.10 and 1.27.3 add a denylist to crypto/x509, causing certificate verification to fail when one of the known untrusted intermediate keys appears in a chain.

Security teams seeking CVE-2026-111943 detection opportunities should look beyond conventional vulnerability exploitation telemetry. This incident is fundamentally about certificate trust, so defenders should monitor TLS certificate chains, unexpected certificate issuers, certificate validation failures, suspicious encrypted sessions, and software that maintains its own certificate bundle rather than relying on rapidly updated browser revocation mechanisms.

SOC Prime’s AI-Native Detection Intelligence Platform enables security teams to strengthen visibility into emerging threats by leveraging continuously updated detection content across diverse SIEM, EDR, and Data Lake technologies. Click Explore Detections to access relevant detection content and hunting logic for emerging attack behaviors.

Security professionals can also use Prime Architect to turn fresh threat intelligence and indicators into hunting queries and detection logic, helping teams Detect CVE-2026-111943-related exposure and investigate suspicious certificate activity across their environments.

Contact Sales

CVE-2026-111943 analysis

The incident began on October 17, 2026, when a security researcher identified a cryptographic weakness affecting eight intermediate certificates operated by eMudhra under its emSign certificate authority infrastructure. The researcher demonstrated possession of the corresponding private keys by submitting valid signed attestations for all eight certificates to browser root programs and eMudhra.

Mozilla subsequently confirmed the compromise and, importantly, reported that its engineers were able to independently recover the affected private keys without receiving details about the researcher’s method. Mozilla concluded that the underlying key-generation process was flawed and straightforward to exploit.

The affected certificate authorities included:

• EM DV TLS CA – G3B
• EM DV TLS CA – G3C
• EM OV TLS CA – G3B
• EM OV TLS CA – G3C
• EM EV TLS CA – G3B
• EM EV TLS CA – G3C
• EM OV CS CA – G3B
• EM OV CS CA – G3C

The first six are TLS intermediates capable of participating in certificate chains used to authenticate websites. The remaining two are code-signing intermediates. The G3B certificates were associated with eMudhra BV in the Netherlands, while the G3C certificates were associated with eMudhra Inc. in the United States.

The security implications are significant. Anyone able to derive or otherwise obtain an intermediate CA private key could potentially issue certificates below that intermediate without going through the legitimate certificate authority issuance process. In the TLS context, fraudulent certificates could be used to impersonate domains if an attacker were also able to intercept or redirect a victim’s connection.

Mozilla noted that such an attacker could potentially impersonate websites and read or modify traffic when positioned to intercept the connection. This makes the issue particularly relevant to adversary-in-the-middle scenarios, compromised network infrastructure, malicious proxies, or DNS and routing manipulation.

However, available evidence does not demonstrate widespread abuse of fraudulent TLS certificates before the defensive response. According to Chrome Root Program findings cited by The Hacker News, no TLS certificate chaining to the six affected website intermediates had appeared in Certificate Transparency logs before Chrome blocked the keys. Because Chrome and other browsers requiring CT logging would normally reject an unlogged publicly trusted certificate, this significantly limited opportunities for undetected public TLS abuse through those clients.

Chrome received the report at 18:05 UTC on October 17 and deployed a CRLSet block for the six TLS intermediates by 19:45 UTC. Mozilla received the report later that evening and distributed a OneCRL block to standard Firefox configurations by 22:59 UTC. Firefox users receiving Remote Settings therefore gained protection without needing to manually update or restart the browser.

The CVE-2026-111943 PoC situation is unusual because this is not a conventional memory-corruption or remote-code-execution vulnerability with exploit code. Instead, the researcher supplied cryptographic proof of control over all eight private keys, and Mozilla independently reproduced the key recovery, effectively demonstrating that the cryptographic failure could be exploited.

The CVE itself has been assigned by the Go Project. It describes a narrower problem involving certificate validation in the Go standard library. On most platforms, Go relies on system root certificate stores. But systems where the relevant trust configuration is not updated promptly could continue accepting chains through intermediates that are no longer trustworthy.

To close that gap, the Go Project added an explicit denylist to crypto/x509. The updated verification logic returns an error whenever a certificate chain contains one of the compromised intermediate public keys.

CVE-2026-111943 affects Go standard library versions before 1.26.10 and the Go 1.27 branch before version 1.27.3. Applications built using affected versions may therefore require rebuilding with a patched Go release to receive the new protection.

The details for CVE-2026-111943 are particularly important for application owners because browser remediation does not automatically protect every program that performs TLS validation. Many applications use language-specific or embedded certificate stores and may not consume browser revocation systems such as Chrome CRLSet or Mozilla OneCRL.

The Hacker News reports that this distinction triggered updates across multiple ecosystems. Go added explicit blocking, Mozilla updated NSS, Python’s certifi certificate bundle removed the affected root, and the Rust webpki-roots ecosystem issued an update. RustSec separately identifies version 1.0.10 or newer as patched for the affected web PKI root package.

The CVE-2026-111943 IOCs are therefore primarily certificate-oriented rather than traditional malware indicators such as IP addresses, domains, or file hashes. Organizations should focus on the eight affected intermediate certificate identities and the public-key hashes used by Go and other vendors to explicitly block those keys. Certificate-chain telemetry showing one of these intermediates should be treated as untrusted and investigated.

CVE-2026-111943 mitigation

The most important remediation for Go environments is to update to Go 1.26.10, Go 1.27.3, or a later supported release and rebuild applications that depend on Go’s TLS certificate verification. Simply upgrading the Go toolchain on a development server does not retroactively change already compiled binaries; affected applications need to be rebuilt and redeployed with the patched standard library.

Organizations should also inventory applications that maintain independent CA stores or certificate bundles. Browsers such as Chrome and Firefox reacted rapidly through centralized revocation mechanisms, but command-line utilities, server applications, containers, agents, embedded devices, and language runtimes may depend on different certificate sources.

Firefox users with normal configurations received the OneCRL block automatically on October 17. Mozilla additionally released Firefox 158.0.1, Firefox ESR 115.43.1, and Firefox ESR 153.5.1 to provide the updated block list to users whose policies or network environments prevented Remote Settings from functioning normally. Mozilla also released NSS 3.131.1 with changes to the trusted certificate set.

Security teams should:

• Update Go applications and rebuild affected binaries.
• Update system CA bundles and language-specific trust stores.
• Ensure browser and operating-system certificate revocation mechanisms are functioning.
• Block or distrust the eight compromised intermediate certificate keys.
• Identify internal applications with embedded or statically packaged certificate stores.
• Inspect TLS telemetry for certificate chains containing the affected intermediates.
• Reissue legitimate certificates if existing services depend on certificate chains that have now been distrusted.
• Test critical services after root-store updates because removing a CA root can also break legitimate services that previously chained through it.

Teams should also pay particular attention to long-lived software appliances, containers, internal developer tools, and unsupported software. These systems may continue trusting old certificate bundles long after mainstream browsers have blocked a compromised CA.

Removing a root certificate may have operational consequences. Legitimate certificates chaining through that root can also stop validating even if those individual certificates were never compromised. For this reason, organizations should combine rapid distrust with dependency discovery and certificate replacement rather than assuming that trust-store removal has no availability impact.

SOC teams can strengthen their defensive posture by correlating certificate validation failures, TLS interception telemetry, unusual DNS activity, unexpected proxy behavior, and certificate issuer changes. An attacker would generally require some mechanism to direct or intercept traffic before a fraudulent TLS certificate becomes useful, so certificate anomalies should be investigated alongside network-level evidence.