AI and security briefsSecurity

Does my Mac, CI runner or server still trust the compromised eMudhra certificates?

By Brandon Da Costa, founder of Digiton Dynamics

Published 28 October 2026Updated 28 October 2026Editorial policy

Possibly. Eight eMudhra intermediate CA keys were recoverable, so anyone holding them can forge a certificate for any website against a client that still trusts them. Apple blocks them in Safari and Mail, but says curl and git on macOS can keep accepting them until a future update. A one-minute test tells you.

Who should act: Anyone who runs git, curl or Python on a Mac or Mac CI runner, or keeps a CA bundle from before the eMudhra fixes on a Linux server, container, Electron app or Java runtime.

What happened

A researcher reported on 17 October 2026 that the private keys of eight eMudhra intermediate CAs were recoverable. Six issue TLS certificates and two sign code. Mozilla recovered the keys itself in under two hours (Mozilla's incident bug). eMudhra revoked all eight on 18 October and says a script error produced weak keys (26 October).

Browsers moved within hours. Chrome and Mozilla blocked the keys on 17 October and are removing the signing root, emSign ECC Root CA - G3 (Google, 20 October). Microsoft blocked the CAs on 20 October and shipped an out-of-band Windows update on 26 October (MSRC). Apple says it has blocked the 12 certificates since 19 October and the root since 23 October.

The gap is the command line. Apple says curl, git, python3, ruby, perl and openssl read /etc/ssl/cert.pem and skip its block until a future software update. A community tracker run by Dennis Jackson reported on 28 October that macOS 27.2, released on 26 October, did not fix it and undid hand edits. Apple's page doesn't mention 27.2.

The sources disagree on dates and risk. The tracker dates Apple's block to 22 October, Apple says 19 October. Chrome says no TLS certificate under the six CAs reached Certificate Transparency before its block, which protects CT-enforcing clients. Per the tracker, curl doesn't enforce CT. I found no report of a live attack.

Who is affected

• Macs using the tools Apple names, CI runners included. A macOS update can restore the file, so recheck after each one.
• Linux servers and containers with a ca-certificates package from before the fixes. The tracker lists fixed builds for Debian, Ubuntu, RHEL, Fedora, Alpine and Amazon Linux.
• Software with its own bundle. The tracker lists fixes in Go 1.27.3, Node.js 24.22.1, Electron 44.9.1 and certifi 2026.10.19, and marks OpenJDK pending.
• Windows machines that skip automatic trust updates.

Tailscale 1.104.2 or later ships Go 1.27.3, which distrusts the certificates even when the system store still holds them (Tailscale, 21 October).

What we checked

Run on 28 October 2026 on the Mac that builds this site. Each command and its output are copied as they ran.

$ sw_vers -productVersion && git --version
26.4
git version 2.39.5 (Apple Git-154)

$ openssl crl2pkcs7 -nocrl -certfile /etc/ssl/cert.pem | openssl pkcs7 -print_certs -noout | grep -E 'emSign ECC Root CA - G3|AAA Certificate Services'
subject=C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=AAA Certificate Services
issuer=C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=AAA Certificate Services
subject=C=IN, OU=emSign PKI, O=eMudhra Technologies Limited, CN=emSign ECC Root CA - G3
issuer=C=IN, OU=emSign PKI, O=eMudhra Technologies Limited, CN=emSign ECC Root CA - G3

$ git ls-remote https://git-emudhra.we-have-a-problem.com/check.git
2975b9930644b321e18ecae09e29c15b955e6103	HEAD
2975b9930644b321e18ecae09e29c15b955e6103	refs/heads/main

Git on this Mac accepted a certificate from the compromised chain and listed the test repository. Both roots Apple names are still in /etc/ssl/cert.pem, so the Mac was not protected yet.

What to do now

1. Test each Mac, runner and server. A certificate error means it is protected. No output means it still trusts the compromised CAs. The hosts belong to the community tracker.

   curl -sS -o /dev/null https://dv-g3b-noct-emudhra.we-have-a-problem.com/
   curl -sS -o /dev/null https://dv-g3b-aaa-noct-emudhra.we-have-a-problem.com/
   git ls-remote https://git-emudhra.we-have-a-problem.com/check.git

2. On Macs, look for the two roots Apple names. If either shows, follow steps 1 to 3 on Apple's page. Tools that read only that file may then fail on some unaffected sites.

   openssl crl2pkcs7 -nocrl -certfile /etc/ssl/cert.pem | openssl pkcs7 -print_certs -noout | grep -E 'emSign ECC Root CA - G3|AAA Certificate Services'

3. On Mac CI, point git at a current bundle, dated 20 October 2026 or later, instead of editing system files.

   curl -o ~/cacert.pem https://curl.se/ca/cacert.pem
   git config --global http.sslCAInfo ~/cacert.pem

4. On Linux, update ca-certificates, rebuild every image built on the old base and rerun step 1 inside it.

   sudo apt-get install --only-upgrade ca-certificates
   docker build --pull --no-cache -t myapp .

5. Compare runtimes with the fixed versions above.

   go version
   node --version
   python3 -m pip show certifi

6. On Windows without automatic updates, install KB5134133 or KB5134125 (BleepingComputer), then replace certificates that chain to the removed roots.

What should have been in place

• An inventory of every trust store you run: system, runtime, container base and bundled apps.
• Certificate Transparency checks in non-browser clients. Chrome says CT-enforcing clients were safe here.
• CI runner images rebuilt on a schedule, so a bundle fix lands within days.
• Lockfile hashes and signed tags, so an intercepted install fails verification.

Questions people ask

Digiton's production review lists every place your systems decide what to trust, and the checks it runs are on the vibe coded app audit page.

How this brief was made: researched from the sources below, drafted with AI assistance and checked against each source on the dates shown. See the editorial policy.

Sources

1. Apple Support, About the compromised eMudhra intermediate CAs, 23 October 2026, read 28 October 2026. https://support.apple.com/en-us/149555
2. Microsoft MSRC, Microsoft's response to compromised eMudhra certificate authority keys, 26 October 2026, read 28 October 2026. https://www.microsoft.com/en-us/msrc/blog/2026/10/microsoft-response-to-compromised-emudhra-certificate-authority-keys
3. Google Chrome Security, Protecting Chrome and Android users from compromised eMudhra intermediate CA certificates, 20 October 2026, read 28 October 2026. https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/
4. Mozilla Bugzilla 2083449, eMudhra private key compromise of intermediate certificates, 18 October 2026, read 28 October 2026. https://bugzilla.mozilla.org/show_bug.cgi?id=2083449
5. eMudhra, statement on recent certificate security incident, 20 October 2026, read 28 October 2026. https://emudhra.com/en/post/certificate-security-incident
6. Tailscale, security bulletins (eMudhra entry of 21 October), 21 October 2026, read 28 October 2026. https://tailscale.com/security-bulletins
7. Community tracker, eMudhra intermediate CA compromise (run by Dennis Jackson), 20 October 2026, read 28 October 2026. https://emudhra.we-have-a-problem.com/
8. Community tracker, Apple's git still trusts the compromised eMudhra certificates, 28 October 2026, read 28 October 2026. https://emudhra.we-have-a-problem.com/apple.html
9. BleepingComputer, Microsoft releases Windows OOB updates to distrust eMudhra certificates, 27 October 2026, read 28 October 2026. https://www.bleepingcomputer.com/news/microsoft/microsoft-releases-windows-oob-updates-to-distrust-emudhra-certificates/
10. Hacker News, Ten days later, Git on macOS still trusts the compromised eMudhra certificates, 28 October 2026, read 28 October 2026. https://news.ycombinator.com/item?id=50271640

More briefs

How these briefs are sourced and corrected. All AI and security briefs