If you use Python for an API, a bot or deployment jobs, review pip, certifi and the tools that download packages. The eMudhra/emSign incident enables HTTPS impersonation against clients that still trust the affected chains. Updating your browser or your own website's certificate does not automatically fix those clients.
Reviewed October 22, 2026. The issue concerns certificate trust and copies of root certificates bundled with software, not a new interpreter memory bug. There are security advisories for certifi and uv, alongside updates to other ecosystem tools.
What is affected, and what could an attacker do?
An attacker with a compromised key and the ability to intercept the connection could present a fraudulent certificate accepted by some clients. This could allow reading or modifying traffic, including downloads. It does not mean PyPI was hacked, all packages contain malware or any Python server can be attacked without those conditions.
The certifi advisory GHSA-6q48-6c7w-9gw2 is rated critical; the uv advisory GHSA-hq85-5cpj-mr62 is rated high. Neither listed an assigned CVE when reviewed; use these GHSA identifiers to follow updates.
The initial certifi advisory lists versions starting at 2019.03.09 and the fix in 2026.10.18. The recommended deployment target is 2026.10.19 or later, for compatibility with unaffected roots. uv versions before 0.13.4 are affected when using the bundled store, which is the default; system or custom stores need their own review.
Recommended versions following the incident
| Component | Reference version | What to check |
|---|---|---|
| certifi | 2026.10.19 or later | Each environment using it; remove G3 without removing unrelated roots. |
| pip | 26.2.2 or later | Its own copy of certifi, not only the application's installed copy. |
| uv | 0.13.4 or later | The executable and CA store it actually uses. |
| sigstore-python | 4.5.1 or later | Local installations and CI tools bundling it. |
| conda | 26.9.4 or later | The base environment, other environments and channel-specific CA packages. |
| Pixi | 0.82.1 or later | The tool; updating it does not update every environment. |
These minimums address this incident, not every possible vulnerability. Use a maintained release compatible with your project. The Python security announcement also calls for reviewing existing virtual environments and rebuilding containers without reusing old layers.
Python 3.15.1, 3.14.9 and 3.13.17: what they fix
On October 21, Python 3.15.1, 3.14.9 and 3.13.17 were released with pip 26.2.2 and its copy of certifi 2026.10.19. The 3.13 branch received a special release with installers despite being in security-only maintenance.
You do not need to jump to Python 3.15 solely for this incident. Update within a compatible branch and review tools separately. An existing virtual environment may retain an older pip after you install the new Python. For distribution-managed packages, check the vendor's advisory and backported fixes; do not force changes onto the system Python.
How to check which installation you are using
Activate the application's virtual environment and run these commands. Replace python with python3 if that is your interpreter's name; on Windows, you can also use your environment's executable path:
python --version
python -m pip --version
python -m pip show certifi
python -c "import sys, ssl; print(sys.executable); print(ssl.OPENSSL_VERSION)"
Your Python API, on a VPS with clear maintenance
Compare TERAMONT VPS plans and define who updates Python, dependencies and certificates in each environment.
The output identifies versions and the interpreter being queried. If pip show certifi cannot find the package, that does not establish that pip is protected: pip bundles its own dependencies. If you use uv, also check uv --version. Repeat the inventory for workers, scheduled tasks, CI and containers; your terminal may use a different environment.
How to update pip and certifi without disabling HTTPS
For a virtual environment you manage, running Python 3.10 or later, the Python team provides this direct pip 26.2.2 installation with a pinned SHA-256. Check the link and hash in the official announcement using an updated client before copying it. The hash must come from a trusted channel; replacing it with one supplied by a suspicious download defeats that check.
python -m pip install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70"
python -m pip install --upgrade "certifi>=2026.10.19"
python -m pip --version
python -m pip show certifi
python -m pip check
If you already have a later patched pip, do not downgrade: skip the first line. Respect dependency files and update their pinned versions through your project's usual workflow. pip check detects declared dependency conflicts, not attacks or the security of all certificates. For system-managed environments, use the system package manager; do not use sudo pip or bypass externally managed environment protections to follow this example.
Updating only the operating system may be insufficient. The pip documentation explains that system certificates are used in addition to certifi. Updating your application's certifi also does not automatically replace the copy inside pip.
If you use uv, Conda or a macOS installer
- uv: update through its installation channel. If you used the standalone installer and the system trust store is already patched, the maintainer suggests
UV_SYSTEM_CERTS=true uv self updatein a compatible shell. Do not assume the store is current. If installed through pip or a system package manager, update through that manager. - Conda: the official procedure includes
conda self update --allwhen conda-self is available, orconda install --name base conda=26.9.4. Updating base does not update every environment. Follow your channel's CA minimums; do not mix managers blindly. - macOS, Python from python.org: review its certifi too. Use the exact interpreter path you installed, such as
/Library/Frameworks/Python.framework/Versions/3.15/bin/python3.15, rather than assuming your terminal command points there.
Our file check: which roots changed in certifi?
On October 22, we locally inspected three official PyPI wheels. We checked each SHA-256 against PyPI metadata served over HTTPS and read the X.509 certificates in certifi/cacert.pem, without installing the packages or opening test connections to vulnerable servers.
| certifi | Certificates in file | emSign roots | ECC Root CA - G3 |
|---|---|---|---|
| 2026.7.22 | 121 | 4 | Present |
| 2026.10.18 | 117 | 0 | Absent |
| 2026.10.19 | 120 | 3 | Absent |
G1, C1 and C3 return in 2026.10.19; G3 remains absent. This explains why the current recommendation is not to indiscriminately delete every emSign root. The count verifies these files, not every trust path an application can use or the absence of an intrusion. Reproducible sources: the 2026.7.22, 2026.10.18 and 2026.10.19 packages.
Before closing the incident on your VPS
- Review every copy: interpreters, pip, uv, virtual environments, bundled applications and custom trust stores.
- Rebuild and deploy: update base images and dependencies without reusing layers that retain old CAs; replace or restart processes that loaded those files.
- Test from the actual application: downloads, APIs, webhooks and important tasks. Do not hide errors with
verify=False,--trusted-hostor unencrypted HTTP. - Keep evidence: versions, deployed image, date and functional results. If interception is suspected, preserve logs and start incident response; updating cannot undo an earlier data leak.
For the origin of the incident and the announced SSL/TLS business exit, read our eMudhra incident guide. If your infrastructure also runs JavaScript, review the Node.js security updates: maintaining one language does not update the other.
If you need infrastructure for an API or bot, compare TERAMONT VPS Hosting and define who maintains each layer. Protection here means deploying and verifying updates, not simply switching providers.
