When a certificate authority falls, your dev tools have to follow

Your IDE downloads a plugin update. The connection is HTTPS, the padlock is there, everything looks fine. Except the certificate guaranteeing that connection was signed by an authority whose keys fell into the wrong hands.

That is the scenario opened in late October by the compromise of certificates from the eMudhra certificate authority. Within days, several tools developers use every day shipped emergency updates.

All of HTTPS security rests on a trust list

When a tool connects over HTTPS, it checks that the server's certificate was signed by an authority it knows. That list of authorities is built into the system, the language or the tool itself.

If an authority is compromised, an attacker can forge a valid certificate for any domain. They can then sit between the tool and the server and change what is downloaded, without anything looking wrong.

The padlock guarantees you're talking to someone certified, not that the certifier can be trusted.

Each ecosystem has its own list, and its own update

What makes this case instructive is the number of tools affected, each with its own fix:

• Go : versions 1.27.3 and 1.26.10 block 8 intermediate authority keys, with no way around it. Internal Go tools must be recompiled ( The Hacker News ).
• Flutter : version 3.47.8 blocks the compromised keys. I need to include it before the next build of Folio .
• Python : the latest releases come with a reminder to update certifi , pip , uv and sigstore , which carry their own trust list.
• JetBrains (PhpStorm, PyCharm, Toolbox): two flaws, CVE-2026-118697 (CVSS 9.0) and CVE-2026-118696 (CVSS 8.0), allowed interception of plugins, repositories and licenses. Update the IDE and Toolbox (3.9.1 or later). Versions 2025.1 and earlier will not be fixed ( JetBrains ).

Updating your system is therefore not enough. A Go binary compiled six months ago or a frozen Python environment keeps the old list.

Dev tools are prime targets

An IDE, a package manager or an SDK downloads code that will end up running on the developer's machine, then in the shipped applications. Intercepting those downloads means reaching everything built afterwards.

No exploitation was reported this time. But the case gives a good list of habits:

• Keep the IDE and its installers up to date, not just the system.
• Recompile internal binaries when the language updates its trust list.
• Update certificate packages in Python environments ( certifi ) and rebuild Docker images.
• Drop tool versions that no longer receive fixes.

And you, do you know which trust list the tools that build your applications rely on?