Electron, we have a problem

Many Electron apps auto-update without verifying signatures. Many also still trust the compromised eMudhra certificates. Together, that lets an attacker on your network install malware on your machine.

If you're a user, uninstall affected apps and install patched versions manually. If you're a vendor, please verify signatures on your auto-updates.

Cypher-SaaS

My hobby this year was breaking the crypto in privacy products like Proton, Internxt and Filen. My biggest gripe with these Cypher-SaaS products is that they rarely admit browser crypto doesn't make sense. They claim that nobody, not even the vendor, can access your data. Yet the vendor could serve a malicious script to a few users and backdoor the encryption. It would be trivial and hard to detect.

The usual advice is to use desktop app instead, where code can be signed and crypto isn't re-fetched on every page load. Because most Cypher-SaaS started off as websites, a common choice is to build desktop clients with Electron. This essentially just bundles the website into a local app running inside a customized browser. However, Electron's update ecosystem is messy and the mainstream libraries only have partial or no signature support, which leads some vendors to skip it and rely on TLS alone to protect the update channel.

eMudhra Intermediate CA Compromise

Then in October 2026, emudhra.we-have-a-problem.com showed that a couple eMudhra intermediate CAs, trusted to sign certificates for any website, used tiny private keys that are trivial to recover.

Browsers fixed it quickly, shipping revocation lists within hours, it didn't even require a browser update. But Electron does not have Chromium's component updater, which is what delivers those lists, so there was no easy remediation. Electron fixed it by hardcoding distrust of these specific eMudhra certs (GHSA), which requires users to install a full new version of any electron application before the patch lands. This is a one-time bandaid and without revocation list support, the next time something similar happens the patching has to repeat.

How bad could it be

This year I reported updates without signature verification to Proton, Bitwarden, Internxt and Filen, so I knew they weren't rare. I had my LLM compile a list of notable Electron apps, install them in a lab, and test which still trust the eMudhra certs (using the new emudhra option in mitmproxy). It then read the code to check whether each app allows in-place updates and, if so, whether they require a signature check.

Scan results by OS. Top left: patched and verifies update signatures (e.g. Signal). Bottom left: still trusts eMudhra but verifies updates (e.g. Bitwarden). Top right: patched but unverified updates (e.g. ProtonMail). Red: unpatched and unverified (e.g. Internxt).

Even if there exists a version that no longer trusts eMudhra, many users still run old versions and without update signatures they patch through an insecure channel which allows remote code execution (RCE) for any attacker on the network.

Here's the full list, a snapshot as of 2026-11-10 with the current state and compiled by an LLM. The landscape is heterogeneous enough that it may have misattributed something, if you spot a mistake I'll fix it but I don't have time to commit and keep it up to date as vendors patch:

¹ Squirrel.exe update traffic does not use the Electron trust store but the OS trust store, so it depends on the OS patch level. Microsoft disallowed the compromised keys in the Windows store in October.

² Proton's desktop apps and Threema pin the certificates of their main API in the app, meaning the main traffic is limited to a small set of certs and does not trust the eMudhra certs. The pin does not apply to the update traffic.

³ Delta Chat rejected the chain despite being unpatched, every connection it makes runs through its Rust core and not the Electron stacks the vulnerability lives in.

Proton Mail patched quickly, but on Windows it still updates without a signature check. Proton pins its own certificates for most traffic, but not for updates, which run in a separate Squirrel.exe process that uses the OS trust store. The same goes for any Windows app using Squirrel which relies on the OS trust store, not Electron's, so an up-to-date OS won't trust the eMudhra certs. One thing I missed in my first review of Proton is how the Proton Mail desktop app fetches its entire UI from mail.proton.me. This is not ideal for an end-to-end encrypted desktop app, as whoever runs the server has the technical means to serve a backdoored UI to selected users on any launch, even if the app itself is properly signed. The same applies to the Padloc password manager and Rocket.Chat.

If you use an app from this list that still trusts the eMudhra certs, uninstall it for now. If it also updates without signatures, don't patch it through the auto-updater. Download the new version in your browser instead, where the compromised CA is already distrusted.

From the Blog

2026-11-03 Filen's password onion made me cry Filen hashes passwords with MD5(MD4(MD2(pwd))). This post shows several cryptographic weaknesses in their protocol and questions if it's even worth doing end-to-end encryption delivered through a webpage. 2026-10-02 Post-Quantum Crypto Won't Fix Your Architecture Adding PQC to this product was like installing a vault door on a tent. The server could intercept your keys and an RCE let attackers run code on your desktop. 2026-06-23 Proton's crypto is not Transparent and not OPAQUE Proton says privacy "isn't a promise, it's mathematically ensured." I found new ways they could read your data anyway.