On October 26, 2026, Apple released macOS Golden Gate 27.2, but developers on a Mac are still missing one fix: the one for the compromised eMudhra certificates. Safari has rejected them since October 19; the system git and curl still accept them [1]. In fact, according to two October 28 sources, the update undid the manual fix [5] [7].

What does that mean, in practice, for a repository clone run over a hotel Wi-Fi network? Just think: anyone on the network path between you and GitHub can pass themselves off as GitHub and hand you code of their choosing [5].

Let’s take it one step at a time: what happened, why it only affects some tools, and what Apple has said as of October 29, 2026.

In short:

As of October 29, 2026, macOS’s own git, curl, and python3 still trust the compromised eMudhra certificates; Safari, Mail, and native apps block them (Apple page of October 23, unchanged on the 29th). If you use them for HTTPS, you’re exposed: you can wait for the promised, undated update or follow Apple’s procedure, which requires an administrator account.

  • October 19 and 23, 2026: Apple blocks the 12 compromised certificates and then the emSign ECC Root CA – G3 root, but only for Safari, Mail, and native apps.
  • October 23, 2026: Apple publishes support page 149555, with a manual procedure for anyone who administers a Mac.
  • October 26, 2026: macOS 27.2 doesn’t fix the problem and, according to a test from October 28, puts the two roots back in /etc/ssl/cert.pem.

What happened to the eMudhra certificates?

The private keys of eight eMudhra intermediate CAs have been compromised, Apple writes [1]. eMudhra is a certificate authority (CA): with its signature it vouches that a TLS certificate, the one behind HTTPS connections, really belongs to a site.

An intermediate CA sits between the root certificate, which systems trust up front, and the certificates of the sites. Two of the eight sign code, the other six sign TLS certificates. With the keys of these six, according to Apple, anyone can create certificates that appear valid for any site [1].

Twelve certificates are involved. Six chain to the emSign ECC Root CA – G3 root; the other six, cross-signed by Sectigo, chain to the AAA Certificate Services root. eMudhra and Sectigo have revoked them [1].

According to Dennis Jackson and the other authors of emudhra.we-have-a-problem.com, the keys were generated incorrectly and could be recovered from the certificates themselves as far back as April 2025 [4]. Whether anyone exploited them is not known: MacRumors reported on October 25, 2026, that there is no evidence of malicious use [8].

Why is Safari protected while git and curl aren’t?

Because they don’t read the same list of certificates. Safari, Mail, and the apps that use Apple’s networking and security frameworks get the block automatically, with nothing to install: the 12 certificates since October 19, 2026, the emSign root since the 23rd [1].

The curl, git, python3, ruby, perl, and openssl that ship with macOS or the Xcode Command Line Tools use /etc/ssl/cert.pem instead, a text file with the root certificates lined up one after another. For certificates that chain to a root in that file, Apple writes, they check neither the block nor revocation [1].

There is also a second difference. Most browsers require every certificate to be in the public Certificate Transparency (CT) logs; curl doesn’t [4]. And in the logs, for these intermediate CAs, no certificate had appeared since April 2025, when the keys first became recoverable [4].

That is why, according to the same authors, Firefox, Chrome, Edge, and Safari could not have been attacked, while for programs outside the browser it is not known [4].

Why did macOS 27.2 put the two roots back in the file?

Because a macOS update can replace /etc/ssl/cert.pem with Apple’s version, which still contains the two roots. Apple says so itself: anyone who removed them by hand has to repeat the check described on page 149555 after every update, until the one with the fix arrives [1].

In the security notes for macOS Golden Gate 27.2, released on October 26, 2026, there is no trace of eMudhra [3]. The Japanese site AAPL Ch. updated a virtual machine running macOS 27.0 to 27.2: after the installation, the two roots were back in the file [7].

The same thing happened with macOS Tahoe 26.7.2, released on the same day [2]. In issue #157 on GitHub, opened on October 27, 2026, a Mac updated from 26.7.1 to 26.7.2 went from 126 to 128 certificates. And the system curl started accepting the test sites that use certificates from the compromised CAs again [4] [6].

The author of the issue also found the two roots in the reference copy of the file that macOS 26.7.2 keeps among its system templates. Their hypothesis, presented as such, is that the update recreates the file from there instead of editing it [6].

What are the risks for developers on a Mac?

A specific condition is needed: someone has to be on the network path and use a certificate signed by one of the compromised CAs. In that position, according to the site of Dennis Jackson and the other authors, they can intercept the HTTPS connections of the tools Apple ships [5].

For git, a clone or pull from an HTTPS address can deliver code chosen by the attacker. A push can be altered along the way, and credentials such as GitHub tokens can be intercepted. The same goes for curl and python3 [5].

Think of an installation script downloaded with curl over a conference network: if the fake certificate gets through, the script that arrives may be a different one.

The picture, however, should be kept in proportion. The major browsers, as mentioned, could not have been attacked [4], and anyone who uses a Mac only with Safari and native apps, Apple writes, doesn’t need to do anything [1]. Apps that ship their own certificate list, such as Electron-based ones, need to be kept up to date instead [4].

This concerns people who work in the Terminal and those who run macOS runners for continuous integration (CI). For the latter, the researchers’ site recommends evaluating the risk to the software supply chain [5].

What does Apple say, and what can you do in the meantime?

Apple writes that the fix will come with a future macOS update and that you won’t need to edit any files [1]. There is no date: MacRumors pointed this out too on October 25, 2026 [8]. As of October 29, 2026, the latest macOS version listed by Apple is still 27.2 [2].

If you don’t want to wait, support page 149555 has the official procedure for removing the two roots from the file [1]. It requires an administrator account and has to be repeated after every update, until the one with the fix comes out.

If it’s a company Mac, the choice is up to whoever manages it: Apple notes that the commands can be deployed through a device management (MDM) solution [1].

The procedure has a cost, and Apple spells it out: without the two roots, tools that use only that file might no longer be able to verify some legitimate sites, the ones that go through intermediate CAs that weren’t compromised [1]. If a pull that used to work starts throwing certificate errors, this may be the reason.

As an alternative to the procedure, some people have git and curl use Homebrew’s list of certificates, which excludes the same two roots [6] [9]: the system file stays untouched, but the same legitimate sites can throw errors.

And other programs, from Node.js to Linux?

It depends on which list of certificates they use. Anything that ships its own list follows its own version, not the macOS one: as of October 28, 2026, the patched versions include, among others, Node.js 26.12.1, 24.22.1, and 22.23.4 and the certifi 2026.10.19 package for Python [4].

If you install the TypeScript 7.1 beta with npm, as in my article, what matters is the Node.js version you have on your Mac.

For Electron-based apps, such as Slack and Discord, the fix only arrives with an update of the app to a version built on a patched Electron [4]. Go, on the other hand, uses system verification on the Mac starting with version 1.18, when the program doesn’t specify roots of its own [10].

On Linux, the major distributions have already updated the ca-certificates package [4]. On a board like the Radxa ROCK 5B from my guide on booting from an NVMe SSD, updating its distribution’s package is enough.

It remains to be seen how long it will take for the update Apple has promised. Until then, for anyone who uses git and curl on a Mac, page 149555 remains the reference to reopen after every macOS update.

Frequently asked questions

Do I need to do anything if I don’t use the Terminal on my Mac?

No. Apple writes that Safari, Mail, and the apps that use its frameworks have blocked the compromised certificates automatically since October 19, 2026. The problem concerns the command-line tools that ship with macOS, such as git, curl, and python3, and the apps that ship their own list of certificates, which need to be kept up to date.

What should I do if I use git or curl on my Mac?

For now, either wait for Apple’s update or follow the procedure on page 149555, repeating it after every update. On company Macs, whoever manages them decides. An alternative is a certificate bundle, a separate file listing the trusted roots, such as Homebrew’s: it excludes the same two roots, so the risk Apple points out for legitimate sites remains.

Does updating macOS already fix the eMudhra certificate problem?

Not yet. As of October 29, 2026, the latest version is macOS Golden Gate 27.2, from October 26, and Apple’s page still mentions a future update. According to tests from October 27 and 28, 26.7.2 and 27.2 actually put the two roots back in the file. When the fix arrives, Apple says, you won’t need to edit any files.

What is an intermediate CA, and what does it mean that it is compromised?

It is a certificate authority that sits between the root certificate and the sites, and signs the sites’ certificates. If its private key is compromised, whoever has it can sign a certificate that appears valid for any site. According to Apple, this happened to eight eMudhra intermediate CAs, six of which sign TLS certificates.

Sources

  1. Apple, “About the compromised eMudhra intermediate CAs” (Apple Support 149555), October 23, 2026, accessed October 29, 2026 – https://support.apple.com/en-us/149555
  2. Apple, “Apple security releases” (Apple Support 100100), updated October 26, 2026, accessed October 29, 2026 – https://support.apple.com/en-us/100100
  3. Apple, “About the security content of macOS Golden Gate 27.2” (Apple Support 149521), October 26, 2026 – https://support.apple.com/en-us/149521
  4. Dennis Jackson and contributors, “eMudhra Intermediate CA Compromise,” October 20, 2026, updated October 28, 2026, accessed October 29, 2026 – https://emudhra.we-have-a-problem.com/
  5. Dennis Jackson and contributors, “Apple’s git still trusts the compromised eMudhra certificates,” October 28, 2026 – https://emudhra.we-have-a-problem.com/apple.html
  6. Issue #157 in the galadran/we-have-a-problem.com repository on GitHub, “macOS 26.7.2 (26 Oct) restores /etc/ssl/cert.pem with both roots; the workaround must be re-applied after every update,” opened October 27, 2026, comments through October 28, 2026 – https://github.com/galadran/we-have-a-problem.com/issues/157
  7. AAPL Ch., article on macOS 27.2 and the restoration of /etc/ssl/cert.pem (in Japanese), October 28, 2026 – https://applech2.com/archives/20261028-macos-updates-may-restore-emudhra-root-ca-certificates.html
  8. MacRumors (Joe Rossignol), “Apple Addresses Web Security Threat, Working on macOS Update With Additional Fix,” October 25, 2026 – https://www.macrumors.com/2026/10/25/apple-blocks-compromised-emudhra-certificates/
  9. Homebrew, ca-certificates formula (stable version 2026-10-20; exclusion of the AAA Certificate Services and emSign G3 roots), accessed October 29, 2026 – https://formulae.brew.sh/formula/ca-certificates and https://github.com/Homebrew/homebrew-core/blob/main/Formula/c/ca-certificates.rb
  10. Go, “Go 1.18 Release Notes,” crypto/x509 section, accessed October 29, 2026 – https://go.dev/doc/go1.18