Lets talk about eMudhra Certificate Vulnerability

A CA’s private key should be a random number up to 116 digits long. One of eMudhra’s was 4.

• What happened: eMudhra, an Indian company that vouches for websites (a CA), made eight secret keys that anyone can guess in under a second.
• Who is affected: people on an updated browser are safe. The risk is in old Go programs, servers with an old list of trusted CAs, and devices that never update.
• What to do: if you ship Go, rebuild and redeploy with Go 1.27.3 or 1.26.10, which block the eight keys (CVE-2026-111943). Then update the CA list in your container images.

What is a CA, and why should you care?

What it is. A certificate authority (CA) is a notary for the internet. It checks that a website really belongs to, say, your bank, and then stamps a certificate for it. A certificate is a digital ID that a website shows your phone or computer.

Where it is used. Behind the padlock in every browser, inside UPI and net-banking apps, on the GST portal and in software updates. It also works between servers you never see: a payment gateway calling a bank API, a KYC check, or your own service calling a partner.

Who uses it. Browsers, phones, servers and any program that opens a secure HTTPS connection.

When. On every connection, in a fraction of a second, before any data moves.

How trust works. A root CA is kept locked away and offline. It signs an intermediate CA, the stamp that is used every day. The intermediate signs your bank’s certificate.

Your phone or server keeps a list of root CAs it trusts. On Linux servers, that list comes from a package called ca-certificates.

When you connect, your app follows the chain back to a root on that list. If every signature checks out, it trusts the site.

The secret key. Every stamp has a secret key (also called a private key), a very large number that only the CA should know. Whoever knows it can stamp a certificate for any website, and every app that trusts the chain will accept it. So the number must be random and impossible to guess.

What went wrong at eMudhra?

eMudhra is a CA based in Bengaluru and listed on the NSE and BSE. Its root CAs are called emSign, and Firefox has trusted them since 2019.

In April 2025, eMudhra made eight new intermediate CAs, so eight new stamps. Six sign website certificates and two sign software.

Each secret key should have been a random number up to 116 digits long. All eight were between 1 and 255. One was 4.

That made them easy to find. The public half of each key is printed in its certificate, which anyone can download.

You try 1, 2, 3 and so on. For each guess, you work out its public half and compare it with the one in the certificate. It takes at most 255 tries, which is under a second on a laptop.

Guessing a properly random key, even at a trillion tries a second, would take far longer than the age of the universe.

eMudhra says a bug in the script it used to make the keys caused this. Mozilla has not verified that.

Who is affected, and how badly?

Most people are not. The risk sits in software that has not received a fix.

In the worst case, someone who sits between you and a server could pretend to be your bank or a partner’s API. Think of a hostile Wi-Fi network or a hacked office network. With a fake certificate, they could read or change the data that passes through.

To do that, they need that spot on the network and a program that trusts these stamps without checking a blocklist. The secret key is no barrier any more, because anyone can work it out.

Nobody has been seen doing this. No certificate made with these stamps shows up in the public logs where certificates are recorded. But the keys were weak from April 2025, so misuse in those 17 months cannot be ruled out.

The problem was reported on 17 October 2026. Firefox blocked the keys in under three hours, and Chrome the same day. Apple followed on 19 October, Microsoft on 20 October, and Go released its fix on 19 to 20 October.

What Go teams must do

The fix lives in Go’s standard library, so it reaches a program only when that program is rebuilt.

1. Find which Go built each binary

A Go program carries the Go version it was built with. Check what is deployed, not your laptop.

go version ./bin/*                 # the Go version inside each binary
go version -m ./bin/app            # plus modules and build settings
grep -E '^(go|toolchain) ' go.mod
grep -rnE 'golang:[0-9.]+' --include='Dockerfile*' .

2. Rebuild and redeploy with Go 1.27.3 or 1.26.10

The fix is compiled into each program. Upgrading Go on your laptop changes nothing that is already running.

go get [email protected]          # or go1.26.10; pins it in go.mod
go build -o ./bin/ ./cmd/...
go version ./bin/app               # expect go1.27.3

If your CI sets GOTOOLCHAIN=local, it ignores the toolchain line, so upgrade the Go in CI or your image tag. Rebuild everything that makes HTTPS calls, including CLIs, sidecars and CI tools. For programs you did not build, install the vendor’s fixed release, such as cloudflared 2026.10.2.

3. Update ca-certificates in your images

The Go fix covers only these eight keys. Your images still need a fresh CA list, because one eMudhra root is being removed. In scratch and distroless images, the list was copied in at build time, so rebuild the image.

FROM golang:1.27.3 AS build
WORKDIR /src
COPY . .
RUN CGO_ENABLED=0 go build -o /out/app ./cmd/app

FROM debian:bookworm-slim
RUN apt-get update && apt-get install -y --no-install-recommends ca-certificates \
    && rm -rf /var/lib/apt/lists/*
COPY --from=build /out/app /usr/local/bin/app
ENTRYPOINT ["/usr/local/bin/app"]

4. If you cannot rebuild yet, add a deny-list

Use this if you are stuck on Go 1.25 or on a fork with no fix. It runs after Go’s normal checks and refuses any chain that passes through one of the eight keys.

Another CA, Sectigo, also signed these keys, so there are 16 certificates. Matching on the key itself catches all of them.

// Package denylist is a stopgap for Go programs you cannot rebuild yet with
// Go 1.27.3 or 1.26.10. It refuses TLS chains that pass through one of the
// eight eMudhra intermediate CA keys that Go blocks (CVE-2026-111943).
package denylist

import (
	"crypto/sha256"
	"crypto/tls"
	"crypto/x509"
	"encoding/hex"
	"errors"
	"strings"
)

// distrustedKeys is the SHA-256 of each blocked public key
// (RawSubjectPublicKeyInfo), the same eight values as Go commit 7f86f95.
const distrustedKeys = `
ebed6475c2c2d80fcb199f3fe8dd6e6b3ce60b77eb15d4e42c3dec0c6f5b5105
49dd353dc2b919a3770645117d0e60c16115e7d1bc259eefe734b00ea434fe5f
e0254c7fcdc265e2f0f8a428dabb75ab4ae039b4872d62f5ee57f0877d5a8a41
5c0660a2b164910d8ff589c18e14552e9e0ec237dcefe2cb736d41a4811f81a0
43bffa19d6ef651451f6841e019931e96f6f2eaeff28ab4b6f1ce4576de2717b
63ecefee431d49523bc1136c4e72d0206a477086caf606cd5cf025686c109cf8
ec4ffa1ad0ac88081314b7aaffef6a91f97cd57291bb5ba686c5415f5eb4f6b6
92c063d67e8f14db71d288e11266ffdaf69cbf115f7bab14f3bc2f68d25e0e30
`

var distrusted = map[[sha256.Size]byte]bool{}

func init() {
	for _, h := range strings.Fields(distrustedKeys) {
		b, err := hex.DecodeString(h)
		if err != nil || len(b) != sha256.Size {
			panic("denylist: bad hash " + h)
		}
		distrusted[[sha256.Size]byte(b)] = true
	}
	if len(distrusted) != 8 {
		panic("denylist: want 8 unique hashes")
	}
}

var ErrDistrusted = errors.New("tls: chain uses a distrusted eMudhra key (CVE-2026-111943)")

func hasDistrustedKey(chain []*x509.Certificate) bool {
	for _, c := range chain {
		if distrusted[sha256.Sum256(c.RawSubjectPublicKeyInfo)] {
			return true
		}
	}
	return false
}

// VerifyConnection runs after Go's normal checks. Like the Go fix, it passes
// only if at least one verified chain avoids all eight keys. Set it as
// tls.Config.VerifyConnection on your HTTP clients and mTLS servers.
func VerifyConnection(cs tls.ConnectionState) error {
	if len(cs.VerifiedChains) == 0 { // nothing was verified: check what the peer sent
		if hasDistrustedKey(cs.PeerCertificates) {
			return ErrDistrusted
		}
		return nil
	}
	for _, chain := range cs.VerifiedChains {
		if !hasDistrustedKey(chain) {
			return nil
		}
	}
	return ErrDistrusted
}

It guards only the connections you wire it into. It is a bridge, not a fix.

5. Never switch off verification

Warning

Do not set InsecureSkipVerify to make new errors go away. It switches off every check, so fake certificates get through too. If a partner breaks, ask them to move to a current chain.

When the old eMudhra root leaves your CA list, partners still on it will fail with errors that start with x509:. Roll out to a few servers first and watch for those errors.

If partners call you with client certificates (mTLS, where both sides show a certificate), build ClientCAs from your partners’ CAs only. A pool built from every public root would also trust these stamps on an old build.

6. Test

For a browser, open the test page. It tries each test site and shows which ones your browser refuses.

For servers, run the test program below from the same host, image and binary as production. Every host should fail. If one connects, that build would accept a fake certificate.

On macOS and Windows, Go asks the operating system to check certificates. I ran the program on a Mac with go1.27.0, which has no fix, and it printed x509: “EM DV TLS CA - G3B” certificate is revoked. That was macOS refusing it, not Go.

A Linux container with an old CA list is the case to worry about.

Test program

Build it with the same Go and base image as your service, and pass it hosts from the test page, such as dv-g3b-emudhra.we-have-a-problem.com.

// Command testhosts dials the upstream eMudhra test hosts and reports what
// this binary's Go version and trust store do with each one. Every host
// should fail verification. A completed handshake means this build would
// accept a certificate that chains through a compromised intermediate.
//
// Usage: go run . [host ...]   (defaults to one host; pass the full list)
package main

import (
	"crypto/tls"
	"crypto/x509"
	"errors"
	"fmt"
	"net"
	"os"
	"runtime"
	"time"
)

func main() {
	hosts := os.Args[1:]
	if len(hosts) == 0 {
		hosts = []string{"dv-g3b-emudhra.we-have-a-problem.com"}
	}
	fmt.Printf("built with %s for %s/%s\n\n", runtime.Version(), runtime.GOOS, runtime.GOARCH)

	accepted := 0
	for _, host := range hosts {
		verdict, err := probe(host)
		fmt.Printf("%-9s %s\n", verdict, host)
		if err != nil {
			fmt.Printf("          %v\n", err) // print the exact error your build returns
		}
		if verdict == "ACCEPTED" {
			accepted++
		}
	}
	if accepted > 0 {
		fmt.Printf("\n%d host(s) accepted: rebuild with Go 1.27.3 or 1.26.10 and update the trust store\n", accepted)
		os.Exit(1)
	}
}

func probe(host string) (string, error) {
	dialer := &net.Dialer{Timeout: 10 * time.Second}
	conn, err := tls.DialWithDialer(dialer, "tcp", net.JoinHostPort(host, "443"), &tls.Config{
		ServerName: host,
		MinVersion: tls.VersionTLS12,
	})
	if err == nil {
		conn.Close()
		return "ACCEPTED", nil
	}

	var (
		invalid x509.CertificateInvalidError
		unknown x509.UnknownAuthorityError
		verify  *tls.CertificateVerificationError
	)
	switch {
	case errors.As(err, &invalid) && invalid.Reason == x509.NoValidChains:
		return "BLOCKED", err // the shape Go's fix returns for these keys
	case errors.As(err, &unknown):
		return "UNTRUSTED", err // the trust store no longer has a root for this chain
	case errors.As(err, &invalid), errors.As(err, &verify):
		return "REJECTED", err // some other verification failure; read the error
	default:
		return "NO TEST", err // DNS, timeout or network: this says nothing about trust
	}
}

What fintech and payments teams must do

Important

No payment impact has been reported. This is a list of places to check, not a finding.

Payment systems check certificates in more places than most teams track:

• Outbound calls to payment gateways, banks, KYC and eSign providers. An old Go service on an old CA list would accept a fake partner certificate.
• Partner mTLS. Trust only the CAs that issue your partners’ client certificates, never every public CA.
• Webhooks you send. The sender is a client too and needs the same fix.
• Code signing and devices. Two of the stamps sign software, and Windows trusts eMudhra’s code-signing root. Confirm your Windows machines have Microsoft’s 20 October block, and ask device vendors when their CA list updates.
• Partner chains. Ask each partner which root their certificates chain to. Calls to partners on emSign ECC Root CA - G3 will fail once that root is removed.
• An inventory of the certificates you trust, the fastest way to answer “are we exposed?”

PCI DSS 4.2.1.1 asks for an inventory of the trusted keys and certificates that protect card numbers in transit. It has been mandatory since 31 March 2025 (summary by Scott Helme).

CERT-In’s directions of 28 April 2022 require some incidents to be reported within six hours, under Direction (ii). Ask compliance whether this counts.

I found no RBI or NPCI rule about certificates, and no source links this incident to any payment system. Whether eMudhra’s digital signature (DSC) and eSign certificates are affected is not established, so ask your provider.

Reference

How an attack would work

An attack needs all four of these at once:

1. The attacker is on the network path between your program and the server, such as a hostile Wi-Fi network.
2. The attacker has one of the eight secret keys. Anyone can now work them out.
3. The attacker signs a fake certificate for the site they want to copy.
4. Your program still trusts the eMudhra chain and checks no blocklist.

Browsers that require Certificate Transparency, public logs that every trusted certificate should appear in, would also reject a fake that was never logged. Logging one would make it public, and none has appeared.

Why cancelling the certificates was not enough

eMudhra cancelled, or revoked, all eight on 18 October. But a cancellation only helps programs that check for one.

Browsers do not wait for that. They ship their own blocklists, which update with the browser (Firefox calls its list OneCRL). Most other programs, including curl and OpenSSL with default settings, do not check for cancellations at all.

As far as I can tell, Go does not check them either. The Go team gave a simpler reason for its fix: many Linux users do not get automatic updates to their CA list. So Go built the block into its standard library.

How fast everyone reacted

Which software has a fix

These rows come from Dennis Jackson’s tracker at Mozilla, through its public repository, and refresh on each sync.

20 of 24 packages patched · 4 pending (FreeBSD, Node.js, Bun, Composer) · synced 2026-10-21 05:50 UTC from galadran/we-have-a-problem.com@bb7c2a8

Pending means no fix is listed yet, not that an attack happened. Java, Android and OpenSSL had made no statement, so a missing row does not mean safe.

Has this happened before?

CAs have failed before, but those cases took weeks to years to settle. Browsers blocked this one within hours.

Viral claims, checked

• Claim: SSL is now broken. Verdict: wrong. The encryption worked, one CA made eight weak keys, and Firefox blocked them in under three hours (Mozilla).
• Claim: avoid public Wi-Fi, or use a VPN, for weeks. Verdict: overstated. Updated browsers reject the fakes, and a VPN on your laptop does nothing for the servers and devices at risk (Scott Helme).
• Claim: anyone can now make a fake HTTPS certificate for any website. Verdict: true, but it gets blocked. Updated browsers, Apple and Microsoft systems and rebuilt Go programs reject such a fake (Mozilla bug 2083449).
• Claim: 60 million certificates can no longer be trusted. Verdict: wrong. That is eMudhra’s own lifetime count, while the problem covers 8 keys in 16 certificates (Mozilla bug 2083449).
• Claim: eMudhra’s private keys leaked. Verdict: wrong. Nothing leaked, because the keys were small enough to work out from the public certificates (Scott Helme).

FAQ

Is HTTPS broken?

No. The encryption worked as designed. One CA made eight weak keys, and updated browsers and rebuilt Go programs block them.

Do I need to change my passwords?

Not because of this. No fake certificate has been seen, and updated browsers reject anything signed with these keys.

Should I avoid public Wi-Fi?

Not if your browser is up to date. The programs at risk are old servers, containers and devices, not an updated browser.

Was anyone attacked?

No attack has been seen. The keys were weak from April 2025, so misuse in that time cannot be ruled out.

My website uses an eMudhra certificate. What should I do?

Your own key is fine. If your chain ends at emSign ECC Root CA - G3, plan to move, because Mozilla and Chrome are removing that root. eMudhra plans to move about 30,000 certificates to its G1 chain, so ask it when yours will move.

Do I need to release a new version of my Go library?

No. The fix lives in the Go version that builds the final program. Tell your users to rebuild with Go 1.27.3 or 1.26.10, and do not raise your go line just for this.

Updates

No tracker changes since publication.

Sources

Start here

• Go issue #82345: the Go team’s tracking issue for the block.
• ThreatLandscape on Go’s hard block: what the Go fix covers.
• we-have-a-problem.com: Dennis Jackson’s tracker, browser test and test hosts.
• Cloudflare’s write-up: how Cloudflare checked and protected its own products.

Primary

• Mozilla bug 2083449: the incident bug, with the timeline and eMudhra’s first report.
• Mozilla bug 1970728: an earlier eMudhra signing problem from 2025.
• Mozilla Security Blog: how Firefox users were protected.
• dev-security-policy thread: Mozilla’s public discussion.
• golang-announce: the Go 1.27.3 and 1.26.10 announcement.
• Go commit 7f86f95: the change that blocks the eight keys.
• Go release history: official release dates.
• eMudhra’s statement: the CA’s own account.
• Debian DSA-6572-1: Debian’s root removal.
• galadran/we-have-a-problem.com: the tracker’s source data.

Analysis

• Scott Helme, Eight bits of trust: a clear walkthrough of the keys and who is exposed.
• The Register: news report.
• LWN: what it means for Linux CA lists.
• The Hacker News: news report.

Background and history

• Introducing OneCRL: how Firefox blocks intermediate CAs.
• Let’s Encrypt ends TLS client authentication: why public CAs rarely issue client certificates now.
• DigiNotar: Mozilla’s 2011 response.
• Microsoft advisory 2982792: the 2014 removal of three NIC CAs.
• Distrusting new CNNIC certificates: Mozilla’s 2015 decision.
• Distrusting WoSign and StartCom: Mozilla’s 2016 decision.
• Chrome’s plan to distrust Symantec: Google’s 2017 schedule.
• Sustaining digital certificate security: Google’s 2024 Entrust decision.
• Debian DSA-1571-1: the 2008 Debian OpenSSL advisory.
• Debian SSLkeys wiki: how many keys the 2008 bug could make.

Regulatory

• CERT-In directions, 28 April 2022: India’s six-hour reporting directions.
• RBI Master Direction on IT Governance: RBI/2023-24/107, with a clause on cryptographic controls.
• RBI Master Direction on IT Outsourcing: RBI/2023-24/102, on IT service providers.
• Scott Helme on PCI DSS 4.0: a summary of requirement 4.2.1.1.