CVE-2026-111943: The Compromised Intermediate CA

An HTTPS connection can look reassuringly ordinary: a lock icon, a familiar domain name, and a few seconds of encrypted traffic. Behind that small lock is a chain of certificates, and CVE-2026-111943 shows what happens when one link in that chain can no longer be trusted.

On October 17, 2026, security teams learned that private keys associated with eight eMudhra intermediate certificates had been compromised. A private key is the secret half of a cryptographic key pair. Whoever controls it may be able to sign new certificates that appear to come from the legitimate certificate authority. Mozilla warned that the keys could be used to create fraudulent HTTPS certificates and impersonate websites during an intercepted connection. eMudhra said the incident did not affect its root CA private keys and that the affected intermediates had not issued end-entity certificates. (blog.mozilla.org)

The CVE is not a flaw that lets Go generate those keys or break the mathematics behind TLS, the protocol that protects HTTPS traffic. It covers the defensive change made in Go’s built-in crypto/x509 package, which parses and verifies digital certificates. That distinction matters: the original problem was a certificate-authority incident, while CVE-2026-111943 describes how Go learned to reject the affected certificates more decisively.

What the Go fix actually does

A CVE, or Common Vulnerabilities and Exposures identifier, gives security teams a shared name for a vulnerability. The official Go vulnerability record calls this issue “Distrust compromised intermediate certificates in crypto/x509.” On most platforms, Go uses the operating system’s collection of trusted root certificates. The problem is that some systems, embedded devices, containers, or custom deployments may not receive a trust-store change quickly enough.

Go’s fix adds a denylist, which is a built-in list of certificates that must not be accepted. The Certificate.Verify function now filters out chains containing the known compromised intermediate certificates. In practice, a Go program using normal certificate verification receives an error instead of treating one of those chains as trustworthy. (pkg.go.dev)

Why an intermediate CA matters

A certificate chain works a little like a delegated signing hierarchy:

Root CA (trusted)
└── Intermediate CA (delegated signer)
 └── api.example.com (server certificate)

A certificate authority, or CA, is an organization trusted to sign digital certificates. A root CA is the trust anchor already present in a device or operating system. An intermediate CA is a subordinate signer that can issue certificates without exposing the root CA’s private key. The final certificate, often called a leaf or end-entity certificate, identifies a website or service.

That middle position makes an intermediate CA valuable. If its private key is compromised, an attacker may be able to sign a new leaf certificate for a site they do not control. A client that sees a valid-looking chain back to a trusted root may accept it unless another control blocks the intermediate. The attack still requires the adversary to get into the connection path, such as through a hostile network or another form of traffic interception. This is a man-in-the-middle attack: the attacker sits between two parties and tries to impersonate one side while relaying or altering the conversation. (blog.mozilla.org)

Why revocation updates can leave a gap

Certificate revocation means declaring a certificate untrustworthy before its expiration date. Certificate Revocation Lists, or CRLs, publish revoked certificates in a signed list. The Online Certificate Status Protocol, or OCSP, lets a client ask whether a certificate is still valid. These systems are useful, but clients do not always check them in the same way, and trust-store updates can lag behind an incident.

Browsers often have extra emergency channels. Mozilla blocked the affected certificates through OneCRL, its centralized revocation list, and later removed the signing root from an updated version of its Network Security Services trust store. Chrome’s root program said it blocked the affected TLS intermediates through CRLSet, while Certificate Transparency logs showed no certificates chaining to those intermediates before the block. A Go binary running in an old container does not automatically receive those browser-specific protections. The Go denylist supplies an application-level backstop.

Which Go versions are affected?

The Go vulnerability database lists crypto/x509 as affected in these ranges:

• Versions before Go 1.26.10
• Go 1.27.0-0 through versions before Go 1.27.3

The fixed releases are Go 1.26.10 and Go 1.27.3. Both were released on October 19, 2026, with security fixes for crypto/x509. The Go team recommended upgrading immediately. (pkg.go.dev)

Start by checking the toolchain used by developers, continuous integration jobs, build containers, and release systems:

go version

A patched toolchain is only the first step. Go’s standard library is compiled into the application during the build, so installing a newer Go version on a server does not retroactively fix binaries already sitting there. Rebuild and redeploy the affected programs, including command-line tools, agents, sidecars, and services that make outbound TLS connections or validate client certificates.

Where the fix appears in an application

A typical Go program eventually reaches Certificate.Verify, either directly or through the standard TLS stack. A simplified verification call might look like this:

verifiedChains, err:= leaf.Verify(x509.VerifyOptions{
 DNSName: "api.example.com",
 Roots: roots,
 Intermediates: intermediates,
})
if err!= nil {
 return fmt.Errorf("certificate verification failed: %w", err)
}

Here, leaf is the server certificate, roots contains trusted root certificates, and intermediates contains the certificates supplied between the server and the root. With a fixed Go release, a chain containing one of the known distrusted intermediates is rejected during verification.

Teams should also review code that sets InsecureSkipVerify, a Go option that disables the normal certificate checks, or code that performs its own verification instead of relying on crypto/x509. Those paths need separate analysis because the denylist may not protect a program that deliberately bypasses standard validation.

A practical response plan

1. Inventory Go versions in source repositories, build images, CI runners, and production containers.
2. Upgrade to Go 1.26.10, Go 1.27.3, or a later fixed release.
3. Rebuild and redeploy every affected Go binary.
4. Update operating-system and container trust stores separately; the Go patch does not repair non-Go clients.
5. Replace any service certificates or chains that depend on a distrusted intermediate, and test both normal and mutual TLS connections.

The incident is a useful reminder that certificate trust is not one file on one computer. It is a living agreement between certificate authorities, browsers, operating systems, language runtimes, and the applications built on top of them. CVE-2026-111943 closes one narrow but important gap: when a known intermediate CA is no longer trustworthy, Go’s verifier now has a reason to fail closed.