A comment on it from Christian Helms adds: Just to stress one point: users must update pip to >= 26.2.2.

pip always loads the CA certificates from its vendored certifi in addition to the system trust store, and there is no supported way to disable this. REQUESTSCABUNDLE / --cert only add CAs; truststore is used “in addition to certifi” by design. As a result, any pip < 26.2.2 will keep trusting the compromised intermediate CAs regardless of the system trust store, so distrusting them at the OS level is not enough. The discuss.python.org conversation on that issue has long since moved on, so asking here:

The macOS remediation advice on the official vuln page at https://emudhra.we-have-a-problem.com/#macos-curl lists remediation instructions which it is claimed address this, with instructions to set a PIPCERT environment variable in a sitecustomize.py file. The built-in pip3, and the pip in virtual environments created from the built-in python3, use their own outdated copy of the roots instead. To make them use the fixed system file, run:

F="$(/usr/bin/python3 -c 'import sysconfig; print(sysconfig.getpath("stdlib"))')/sitecustomize.py" && echo 'import os; os.environ.setdefault("PIPCERT", "/etc/ssl/cert.pem")' | sudo tee -a "$F" > /dev/null && sudo chmod 644 "$F"

I'm finding it a bit tricky to figure out a reproducible test case which would exercise this, so I haven't done more testing myself, but—does this actually work? Or is upgrading pip to >= 26.2.2 the only solution? (Or, now that pip > 26.2.2 is out, is upgrading the better solution, and I should go file a PR against the site to update its guidance.)

(Incidentally, the latest macOS updates do NOT include an updated /etc/ssl/cert.pem, and do clobber any manual changes you or your IT department may have made to /etc/ssl/cert.pem, so any manual mitigations you have applied to remove the AAA Certificate Services and emSign ECC Root CA - G3 certs DO need to be reapplied.)

Best, - Kevin

On Thu, Oct 22, 2026 at 4:43 PM Alan Coopersmith <alan.coopersmith () oracle com> wrote: https://discuss.python.org/t/information-for-python-users-regarding-emudhra-emsign-ca-certificate-security-incident/109576 has this statement from Seth Michael Larson: A security incident affecting eMudhra intermediate certificates has required removing the emSign root CA certificate from CA bundles such as “certifi”. It’s important to immediately upgrade the software packages below to at least the versions specified and rebuild container images with layer caching disabled to fetch the latest system certificates. Failure to do so could result in monster-in-the-middle (MITM) attacks against TLS clients, including python.org and pypi.org .

certifi 2026.10.19 (1) pip 26.2.2 uv 0.13.4 sigstore 4.5.1 conda 26.9.4 pixi 0.82.1

(1): Advisory mentions 2026.10.18, but 2026.10.19 is recommended for compatibility with unaffected emSign root certificates.

For all existing virtual environments on your system, please upgrade pip and uv to the latest versions. You can update pip securely by running the following command and then use this secure pip installation to upgrade certifi and uv:

python -m pip install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70";

Note that the certifi CA bundle is included in the macOS installation of Python from python.org. To upgrade certificates for this installation and pip itself, run the command below like so:

/Library/Frameworks/Python.framework/Versions/3.15/bin/python3.15 -m pip install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70"; /Library/Frameworks/Python.framework/Versions/3.15/bin/python3.15 -m pip install --upgrade certifi /Library/Frameworks/PythonT.framework/Versions/3.15/bin/python3.15t -m pip install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70";

This topic will be updated as more information is made available. A comment on it from Christian Helms adds: Just to stress one point: users must update pip to >= 26.2.2.

pip always loads the CA certificates from its vendored certifi in addition to the system trust store, and there is no supported way to disable this. REQUESTSCABUNDLE / --cert only add CAs; truststore is used “in addition to certifi” by design. As a result, any pip < 26.2.2 will keep trusting the compromised intermediate CAs regardless of the system trust store, so distrusting them at the OS level is not enough.

uv users can block the bad certs in their system trust store and UVSYSTEMCERTS=true. That does not work with pip. Updating pip is the only reliable fix. See Switch to using truststore only by default (currently mixed certifi + truststore) · Issue #14374 · pypa/pip · GitHub

PS: The ‘security incident’ is a bad private key. An elliptic key with private key value d=4 is not secure… All 8 eMudhra CAs had private keys with d < 256.

-- Kevin Riggle - Principal, Complex Systems Group LLC he/him • Brooklyn, NY, USA • Eastern Time https://complexsystems.group • https://calendly.com/kevinriggle/coffee

On Wed, Oct 21, 2026 at 6:16 PM Jakub Wilk <jwilk () jwilk net> wrote: Solar Designer <solar () openwall com>, 2026-10-21 07:54: On Tue, Oct 20, 2026 at 03:44:34PM -0400, Jeffrey Walton wrote: It is probably worth noting the Comodo AAA Services Root removal is not related to the eMudhra incident. Are you sure? Doesn't it cross-sign the compromised intermediates? It does cross-sign them. Yes, you're correct. My bad. Ugh...

Comodo AAA Services Root had the TLS trust bit removed in April 2025, and that meant it was dropped from Browser trust stores and some tooling. However, the certificate could still be used for S/MIME. Confer, <https://www.openwall.com/lists/oss-security/2026/10/22/12>. The issue with Comodo AAA Services Root was the removal of the TLS trust bit by browsers because the root is too old. The current CA/Browser (CA/B) Baseline Requirements (BR) policies say a root has a maximum lifespan of 15 years from creation date. Comodo AAA Services Root was issued in 2004, so it violates current policy. Also see <https://cabforum.org/working-groups/server/baseline-requirements/>. FWIW, I couldn't find such a requirement in CA/B BR. My bad again. The notAfter is specified in the CA/B BR Section 7.1.2.1.1, Root CA Validity. And it is 25 years.

The reason the trust bit was removed from Comodo AAA Services Root was due to root program policies implemented by Mozilla and Chrome, not the CA/B BR. It happened in April 2025. So software like Google Chrome, Mozilla Firefox, NSS and ca packages like certifi lacked the certificate.

Ugh, I've got to do a better job in the future. This may be right, but perhaps the urgency to remove it now is related to the eMudhra incident?

Incidentally, it is not yet removed in NSS 3.131.1, which does remove the emSign certs. An omission to fix in a further update urgently? AFAICT the Comodo AAA cert hasn't been removed from NSS, but it had the web trust bit turned off last year: https://bugzilla.mozilla.org/showbug.cgi?id=1957685 Yes. That said, my Firefox 153 ESR (which is supposed to include that change) still trusted the Comodo AAA cert, so I'm confused. Yeah, I am confused, too. Chrome and Firefox removed Comodo AAA Services Root in April 2025. I'm not sure why it would be present in Firefox 153 ESR.

Jeff

The Python ecosystem is pushing towards using https://pypi.org/project/truststore/ rather than solutions like certifi. This incident will likely help increase the priority of that transition.

On Fri, 2026-10-23 at 00:07 +0300, Valtteri Vuorikoski wrote: Having spent the day whacking this particular molehill, my strong opinion is that these packages (minus certifi) should stop vendoring roots immediately.

Users should install their distro's ca-certificates package or similar. If that is completely impossible for whatever reason, offer an option to use certifi (which should be a dependency, not vendored) - but the system trust store should be the default source of truth.

This sort of easter egg hiding to serve users with broken installations reduces the security of everyone else.

(Missing from the quoted list: botocore also includes a vendored copy. I haven't checked how it's used.)

-valtteri

On Thu, Oct 22, 2026 at 01:43:08PM -0700, Alan Coopersmith wrote: https://discuss.python.org/t/information-for-python-users-regarding-emudhra-emsign-ca-certificate-security-incident/109576 has this statement from Seth Michael Larson: A security incident affecting eMudhra intermediate certificates has required removing the emSign root CA certificate from CA bundles such as “certifi”. It’s important to immediately upgrade the software packages below to at least the versions specified and rebuild container images with layer caching disabled to fetch the latest system certificates. Failure to do so could result in monster-in-the-middle (MITM) attacks against TLS clients, including python.org and pypi.org .

certifi 2026.10.19 (1)     pip 26.2.2     uv 0.13.4     sigstore 4.5.1     conda 26.9.4     pixi 0.82.1

On 10/22/26 5:07 PM, Valtteri Vuorikoski wrote: Having spent the day whacking this particular molehill, my strong opinion is that these packages (minus certifi) should stop vendoring roots immediately.

Users should install their distro's ca-certificates package or similar. If that is completely impossible for whatever reason, offer an option to use certifi (which should be a dependency, not vendored) - but the system trust store should be the default source of truth.

This sort of easter egg hiding to serve users with broken installations reduces the security of everyone else.

(Missing from the quoted list: botocore also includes a vendored copy. I haven't checked how it's used.) This is why using packages from a Linux distro is good: linux distro provided "certifi" packages typically are patched or outright build from https://github.com/projg2/certifi-system-store, to use, well, the system store.

And pip is unbundled to use the system certifi. Well ok, technically it is unbundled to use the system requests, and the system requests uses the system certifi.

sigstore's "update" was updating a lockfile to lock newer certifi, they didn't even actually add a >= dependency on "new enough to have the eMudhra fix" so the whole thing is actually ludicrous. If you had sigstore installed before a couple days ago, upgrading sigstore won't upgrade your certs, and if you actually updated all packages then certifi would be updated regardless of whether sigstore tagged a new version.

conda actually responded by adding a dependency constraint to >= the suitable version of certifi.

uv / pixi are rust software, which means a) infinite vendoring, b) cargo build will usually error out if you try to patch anything to unvendor it, so, "good luck" (and also stick to pip IMO).

...

This is why vendoring is always fundamentally treated with such suspicion. We have had ample proof over the decades that issues like this will just continue to crop up again and again, in so many various ways, despite what the

"AcKshUAlLY sTaTIc LinkING iS MORE efFiCIEnt"

crowd says.

Python vendored packages is just static linking with the additional possibility of trivial monkeypatching.

-- Eli Schwartz

https://discuss.python.org/t/python-3-15-1-3-14-9-and-3-13-17-are-out/109595 announces: Here are expedited security releases of Python 3.15 and 3.14, and a special security release of 3.13.

Python 3.15.1 Python 3.14.9 Python 3.13.17

They all upgrade the bundled pip to version 26.2.2, which includes certifi 2026.10.19 to address the eMudhra / emSign CA certificate security incident.

We don’t normally update pip for security releases like Python 3.13 because of backward compatibility concerns, but since 3.13 only just entered security-only mode, doing a special release with installers seemed prudent.

See the Discourse announcement for more information.

For all existing virtual environments on your system, please upgrade pip and uv to the latest versions.

To upgrade pip securely within a virtualenv:

python -m pip install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70";

If you cannot immediately upgrade to this release, you can upgrade certificates for a Python 3.15 macOS installation and pip itself via:

/Library/Frameworks/Python.framework/Versions/3.15/bin/python3.15 -m pip install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70"; /Library/Frameworks/Python.framework/Versions/3.15/bin/python3.15 -m pip install --upgrade certifi /Library/Frameworks/PythonT.framework/Versions/3.15/bin/python3.15t -m pip install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70";

For 3.14:

/Library/Frameworks/Python.framework/Versions/3.14/bin/python3.14 -m pip install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70"; /Library/Frameworks/Python.framework/Versions/3.14/bin/python3.14 -m pip install --upgrade certifi /Library/Frameworks/PythonT.framework/Versions/3.14/bin/python3.14t -m pip install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70";

For 3.13:

/Library/Frameworks/Python.framework/Versions/3.13/bin/python3.13 -m pip install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70"; /Library/Frameworks/Python.framework/Versions/3.13/bin/python3.13 -m pip install --upgrade certifi /Library/Frameworks/PythonT.framework/Versions/3.13/bin/python3.13t -m pip install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70";

macOS 27.0 IDLE and tkinter

Additionally, the macOS installer for this release is built with a pre-release of Tk, fixing a possible hang on macOS 27.0 in applications using tkinter, like IDLE, in older releases.

Enjoy the new release

Thanks to all of the many volunteers who help make Python development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organisation contributions to the Python Software Foundation.

Your certified release team, Hugo van Kemenade Thomas Wouters Ned Deily Steve Dower

Having spent the day whacking this particular molehill, my strong opinion is that these packages (minus certifi) should stop vendoring roots immediately.

Users should install their distro's ca-certificates package or similar. If that is completely impossible for whatever reason, offer an option to use certifi (which should be a dependency, not vendored) - but the system trust store should be the default source of truth.

This sort of easter egg hiding to serve users with broken installations reduces the security of everyone else.

(Missing from the quoted list: botocore also includes a vendored copy. I haven't checked how it's used.)

-valtteri

On Thu, Oct 22, 2026 at 01:43:08PM -0700, Alan Coopersmith wrote: https://discuss.python.org/t/information-for-python-users-regarding-emudhra-emsign-ca-certificate-security-incident/109576 has this statement from Seth Michael Larson: A security incident affecting eMudhra intermediate certificates has required removing the emSign root CA certificate from CA bundles such as “certifi”. It’s important to immediately upgrade the software packages below to at least the versions specified and rebuild container images with layer caching disabled to fetch the latest system certificates. Failure to do so could result in monster-in-the-middle (MITM) attacks against TLS clients, including python.org and pypi.org .

certifi 2026.10.19 (1) pip 26.2.2 uv 0.13.4 sigstore 4.5.1 conda 26.9.4 pixi 0.82.1

https://discuss.python.org/t/information-for-python-users-regarding-emudhra-emsign-ca-certificate-security-incident/109576 has this statement from Seth Michael Larson: A security incident affecting eMudhra intermediate certificates has required removing the emSign root CA certificate from CA bundles such as “certifi”. It’s important to immediately upgrade the software packages below to at least the versions specified and rebuild container images with layer caching disabled to fetch the latest system certificates. Failure to do so could result in monster-in-the-middle (MITM) attacks against TLS clients, including python.org and pypi.org .

certifi 2026.10.19 (1) pip 26.2.2 uv 0.13.4 sigstore 4.5.1 conda 26.9.4 pixi 0.82.1

(1): Advisory mentions 2026.10.18, but 2026.10.19 is recommended for compatibility with unaffected emSign root certificates.

For all existing virtual environments on your system, please upgrade pip and uv to the latest versions. You can update pip securely by running the following command and then use this secure pip installation to upgrade certifi and uv:

python -m pip install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70";

Note that the certifi CA bundle is included in the macOS installation of Python from python.org. To upgrade certificates for this installation and pip itself, run the command below like so:

/Library/Frameworks/Python.framework/Versions/3.15/bin/python3.15 -m pip install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70"; /Library/Frameworks/Python.framework/Versions/3.15/bin/python3.15 -m pip install --upgrade certifi /Library/Frameworks/PythonT.framework/Versions/3.15/bin/python3.15t -m pip install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70";

This topic will be updated as more information is made available. A comment on it from Christian Helms adds: Just to stress one point: users must update pip to >= 26.2.2.

pip always loads the CA certificates from its vendored certifi in addition to the system trust store, and there is no supported way to disable this. REQUESTSCABUNDLE / --cert only add CAs; truststore is used “in addition to certifi” by design. As a result, any pip < 26.2.2 will keep trusting the compromised intermediate CAs regardless of the system trust store, so distrusting them at the OS level is not enough.

uv users can block the bad certs in their system trust store and UVSYSTEMCERTS=true. That does not work with pip. Updating pip is the only reliable fix. See Switch to using truststore only by default (currently mixed certifi + truststore) · Issue #14374 · pypa/pip · GitHub

PS: The ‘security incident’ is a bad private key. An elliptic key with private key value d=4 is not secure… All 8 eMudhra CAs had private keys with d < 256.