Command line tools on a Mac read TLS certificates from a file that macOS updates do not touch, and the company that recently lost control of its signing keys is still listed inside it. Apple’s block on those certificates covers the frameworks, not this path.
Eclectic Light’s Howard Oakley laid out the gap on October 29. Nobody at eMudhra made its intermediates hard to reproduce, and at least one signing key amounted to the number 4.
Apple applied the block across iOS, iPadOS and macOS, so anything validating through its security frameworks is covered. Utilities such as curl go their own way, reading a static bundle at /etc/ssl/cert.pem that point releases never rewrite. A forged chain signed with one of those keys would sail past such a tool.
What to delete by hand
Apple has published steps for removing the compromised roots from that bundle, and they must be repeated on every Mac you own. A shell with noclobber enabled will reject two of the commands; swapping the single redirect for a doubled one avoids the error.
Getting a corrected bundle onto every machine is the harder problem. Oakley suggests folding it into updates for Sequoia, Tahoe and Golden Gate. Releases older than that lack an obvious delivery path.
The wider month
Two critical PHP flaws are under active attack in the same stretch, though a public web server on a Mac is rare enough that few owners are exposed. A memory corruption bug in the TianoCore firmware project that underpins most servers misses Macs entirely, since Apple silicon skips UEFI and Intel models never used the affected code.
Electron programs inherit a fix only when rebuilt against a patched runtime, and a test page that checks trust in a compromised authority beats reading advisories.
