mitmproxy adds --emudhra option to sign certs with compromised CA key
Archived — this story has rotated out of today’s deck. It is kept here in full.
The gist
The mitmproxy tool added an --emudhra option that signs TLS certificates with a compromised eMudhra intermediate CA key.
The flag turns a certificate-authority breach into a ready-made interception tool for testing.
Background
mitmproxy is a tool for intercepting and inspecting TLS traffic, and mhils is the developer who authored the change. eMudhra is a certificate authority whose intermediate CA private keys were found compromised in October 2026, prompting vendors like Fortinet to publish mitigation guidance. The new boolean option, off by default, loads the eMudhra chain so mitmproxy can sign certificates with the compromised key — arriving alongside a companion change that removed eMudhra CAs from certifi precompiled binaries.
How it unfolded
- Oct 17, 20268 private keys held by eMudhra intermediate CA certificates were proven compromised.
- Oct 20, 2026The eMudhra intermediate CA key compromise became public information.
- Oct 21, 2026Fortinet published guidance on protecting endpoints affected by the compromise, and a Mastodon post noted the eMudhra CA certificate could be dropped into mitmproxy for fully trusted TLS interception.
- Oct 22, 2026A Hacker News submission titled "mitmproxy adds --emudhra option" was posted by ahlCVA and reached 8 points.
- date unknownmitmproxy commit 1692344 by mhils added the --emudhra option (PR #8500), changing 6 files with +139/-9 lines; the CHANGELOG describes it as signing TLS certificates with a compromised eMudhra intermediate CA key.
Who’s saying what
- Caution
- Fortinet says any endpoint trusting the emSign Root TLS CA - G3 or AAA Certificate Services is vulnerable to MITM and strongly recommends removing those root certificates, though it notes attacks require an attacker to control a device in the traffic path.
- Expert
- Commenter eqvinox says the private key for all 8 "compromised" CAs is a single byte and one key is literally "4", putting "compromised" in quotes.
- Analysts
- Commenter woodruffw says certificate transparency will give a definitive answer on whether the keys were exploited, while agwa says no certificates from the compromised intermediates were logged to CT prior to browser remediation.
- Public
- Commenter hbcdbff says it was almost certainly noticed and quietly exploited by a state actor, and argues CT is largely irrelevant for traffic fetched outside a browser.
Still unverified
Whether the compromised keys were exploited is disputed: hbcdbff claims a state actor almost certainly exploited it, while woodruffw and agwa point to CT logs, with agwa saying no certificates from the compromised intermediates were logged prior to browser remediation. It is also questioned whether eMudhra will remain in business after the certificates with incorrectly generated keys were revoked.