certifi emSign Root CA Removal: Update to 2026.10.19

The Python package certifi, which ships the CA bundle used by many Python HTTPS clients, included a root certificate whose chain contains intermediate CAs with compromised private keys. According to the GitHub advisory GHSA-6q48-6c7w-9gw2, certifi versions before 2026.10.18 trust the emSign ECC Root CA - G3, and eight eMudhra intermediates under it have been revoked after their keys were compromised.

If you run Python services, deployment scripts, CI jobs or container images that make outbound HTTPS calls, this is worth checking today. The fix is a package upgrade, but images that bundle certifi need a rebuild as well.

What happened

Certifi is a curated list of trusted root certificates. Python tools use it to decide whether a server's TLS certificate is genuine. Per the advisory, versions before 2026.10.18 include the emSign ECC Root CA - G3. Eight eMudhra intermediate CA certificates chain to that root, their private keys are compromised, and the CA has revoked them.

A certificate authority's trust works top down: if a client trusts the root, it trusts anything signed by an intermediate beneath it. Someone holding a compromised intermediate key can therefore mint certificates for any hostname that look valid to a client trusting that root. The advisory says that an attacker who is also on-path can intercept or modify TLS traffic from clients that trust the certifi bundle.

The advisory names requests, urllib3 and pip as examples of affected clients, along with the Python.org macOS installer. The maintainers link to a Python community discussion about the eMudhra emSign incident for further context.

Technical details and real-world risk

The advisory's CVSS v4 vector lists a network attack vector, high attack complexity, present attack requirements, no privileges and no user interaction, with high confidentiality and integrity impact on the vulnerable system. The high complexity and attack requirements reflect that exploitation needs both a compromised key and a network position between client and server.

That makes this a different risk from a remote code execution bug. Nothing is exploited on your server directly. Instead, the trust decision your Python client makes about a remote server becomes unreliable for certificates chaining to the affected intermediates. The most exposed traffic is outbound: API calls, package downloads, webhooks and calls to payment or cloud services made over untrusted or shared networks.

Who is affected

• Applications and scripts using requests, urllib3 or other clients that load certifi's bundle, on certifi versions from 2019.03.09 up to but not including 2026.10.18.
• Developer and CI machines running pip with an affected certifi, since pip is named in the advisory.
• Container images and virtual environments that vendor certifi. Upgrading the host does not change a copy baked into an image.
• macOS users of the Python.org installer, which the advisory lists as an example.

Servers that never make outbound TLS connections from Python are less exposed, but certifi is often installed as a transitive dependency, so check rather than assume.

How to check your exposure

This read-only command prints the certifi version installed in the current Python environment. Run it in each virtualenv, container and host you manage. Any version below 2026.10.18 is affected.

python -m pip show certifi

This lists which installed packages depend on certifi, which helps you find where it comes from.

python -m pip show certifi | grep -i required-by

Also search your repositories for pinned versions in requirements files and lock files, and check base images and Dockerfiles that install certifi or copy a virtualenv into the image.

What to do now

Upgrade to certifi 2026.10.19 or later, as the advisory recommends. Version 2026.10.18 removed all emSign roots, and 2026.10.19 restored the ones that are not affected, so 2026.10.19 is the target.

python -m pip install --upgrade "certifi>=2026.10.19"

Detection and monitoring

Because the attack happens on the network path, it leaves little trace on your server. The practical defense is keeping trust stores current and watching the certificates your own sites present. Certificate monitoring can alert you when a certificate on your domains changes unexpectedly, and the free SSL certificate checker lets you look at the chain a site currently serves. These help you watch your own public endpoints. They cannot see which CA bundle your Python clients trust, so the version checks above are still needed.

Going forward, add a dependency audit step to CI so outdated certifi releases are flagged, and keep a record of which images carry their own CA bundle.

Timeline

Sources

This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.

1. GHSA-6q48-6c7w-9gw2 - GitHub Advisory Databasegithub.com · 20 October 2026

• certifi
• Python
• TLS
• certificate authority
• supply chain
• containers