---
title: "Versões de emergência do Python: atualize o pip"
description: "Chaves fracas na autoridade certificadora emSign levaram o Python a versões de emergência. Veja por que o pip antigo fica exposto e como atualizar."
canonical: https://wmj.com.br/insights/versoes-de-emergencia-do-python-atualize-o-pip/
date: 2026-10-22
---

# Versões de emergência do Python: atualize o pip

Chaves fracas na autoridade certificadora emSign levaram o Python a versões de emergência. Veja por que o pip antigo fica exposto e como atualizar.

**Em resumo:** Em 21 de outubro de 2026, o Python lançou as versões de emergência 3.15.1, 3.14.9 e 3.13.17. O defeito não está no Python: oito certificados intermediários da emSign, a autoridade certificadora da eMudhra, tinham chaves privadas tão fracas que qualquer um podia calculá-las. Com elas, um atacante se passa por qualquer site, inclusive o pypi.org, para os programas que ainda confiam nesses certificados. A correção é atualizar o pip para 26.2.2 e o certifi para 2026.10.19 em todo ambiente Python, e não só o Python.

## O que aconteceu

Uma autoridade certificadora (CA) é a empresa que assina os certificados do HTTPS. Navegadores e programas confiam numa lista de CAs raiz, e tudo o que elas assinam, direto ou por CAs intermediárias abaixo delas, vale como verdadeiro.

Em 17 de outubro, um pesquisador avisou os navegadores e a eMudhra de que oito CAs intermediárias da emSign, criadas em abril de 2025, tinham a chave privada com valor menor que 256. Nesse tipo de chave, o valor deveria ser um número enorme, de 384 bits. Com um valor tão pequeno, a chave se descobre na hora. Para provar, ele assinou uma mensagem com cada uma delas.

Os navegadores reagiram em horas. Chrome e Firefox bloquearam as intermediárias no mesmo dia 17, a eMudhra as revogou no dia 18 e, em 20 de outubro, o Mozilla retirou a confiança na raiz "emSign ECC Root CA - G3". A eMudhra diz que essas intermediárias não emitiram certificados e que não tem evidência de uso malicioso antes do aviso. O Mozilla relatou que várias pessoas conseguiram recuperar as chaves por conta própria.

Os navegadores atuais só aceitam certificados registrados no Certificate Transparency, o registro público de certificados, e não há registro de certificados emitidos por essas intermediárias. Por isso, segundo o resumo do incidente, quem usa navegador não poderia ter sido atacado por esse caminho. Muitos programas fora do navegador não fazem essa checagem. É aí que entra o Python.

## Por que o Python precisou de versões novas

O pip, o instalador de pacotes do Python, carrega a lista de CAs do pacote certifi, que vem embutido nele, além da lista do sistema. Atualizar os certificados do sistema operacional não basta: um pip antigo continua confiando na raiz da emSign pela cópia própria. As opções `--cert` e `PIP_CERT` só acrescentam CAs, não tiram.

O certifi 2026.10.19 retira a raiz afetada, e o pip 26.2.2, de 20 de outubro, traz essa versão. As versões 3.15.1, 3.14.9 e 3.13.17 do Python trazem o pip novo no ensurepip, o módulo que instala o pip em cada ambiente virtual criado.

O aviso oficial do Python fala em risco de ataque de intermediário (MITM): alguém na rede entre você e o servidor se passa por python.org ou pypi.org e entrega o que quiser. O pypi.org não foi invadido. O problema está nos programas que ainda confiam nas chaves vazadas.

## Quem está exposto

- **Todo pip anterior ao 26.2.2,** em qualquer ambiente virtual, imagem de container ou servidor de CI. Cada ambiente virtual guarda o próprio pip.
- **Quem usa requests ou httpx.** Os dois usam o certifi instalado no ambiente e precisam dele atualizado.
- **Quem usa urllib ou o módulo `ssl` direto.** Eles usam a lista de CAs do sistema e dependem do pacote `ca-certificates` da distribuição.
- **O Python do python.org no macOS.** Ele usa um certifi próprio, não a lista do sistema.
- **Quem está no Python 3.12 ou 3.11.** Essas linhas não ganharam versão nova, e todo ambiente virtual criado com elas nasce com pip antigo (24.0 na 3.11, 25.0.1 na 3.12). O 3.10 já saiu do suporte e não recebe nada.
- **Imagens Docker oficiais do Python.** As de 3.13 a 3.15 foram atualizadas em 21 de outubro. As de 3.11 e 3.12 continuam com pip antigo.

## Como verificar

Em cada ambiente virtual, e dentro de cada container:

```bash
python -m pip --version
python -m pip show certifi
```

O pip precisa estar na 26.2.2 ou mais nova, e o certifi na 2026.10.19 ou mais nova. Se usa o uv, confira com `uv --version`: o mínimo é a 0.13.4.

## O que fazer

- **Atualize o pip pelo comando do aviso oficial.** O hash no fim do endereço garante que o arquivo é o publicado no PyPI, mesmo que alguém intercepte a conexão. Depois, use esse pip para atualizar o certifi:

```bash
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
```

- **Repita em todos os ambientes virtuais.** No Python 3.12 ou 3.11, faça isso também logo depois de criar um ambiente novo.
- **No macOS, com o Python do python.org,** rode os mesmos comandos com o Python do framework, por exemplo `/Library/Frameworks/Python.framework/Versions/3.15/bin/python3.15`. O aviso traz o comando para cada versão.
- **Atualize o Python** para 3.15.1, 3.14.9 ou 3.13.17, se estiver numa dessas linhas.
- **Reconstrua as imagens de container sem cache** (`docker build --no-cache`), como pede o aviso, para pegar os certificados novos do sistema. Num Dockerfile com Python 3.12 ou 3.11, acrescente a atualização do pip.
- **Atualize os certificados do sistema.** No Debian e no Ubuntu: `sudo apt update && sudo apt install --only-upgrade ca-certificates`.
- **Atualize as outras ferramentas** para pelo menos uv 0.13.4, conda 26.9.4, pixi 0.82.1 e sigstore 4.5.1, os mínimos do aviso.

## Próximos passos

Foi uma semana de correções de emergência. No Python, ela começou com [três falhas no Pillow](/insights/tres-falhas-no-pillow-atualize-para-o-13-0-0/), a biblioteca de imagens: se o seu sistema recebe imagens de fora, confira também a versão dele. Se você mantém servidores com PHP, veja o nosso post sobre o [PHP2Shell](/insights/php2shell-falhas-criticas-no-php/). Se quiser ajuda para revisar ambientes virtuais, imagens e servidores, fale com a gente sobre a [gestão de servidores](/servicos/gestao-de-servidores/).

## Fontes

- [Python: aviso sobre o incidente com os certificados da eMudhra/emSign](https://discuss.python.org/t/information-for-python-users-regarding-emudhra-emsign-ca-certificate-security-incident/109576)
- [Python Insider: Python 3.15.1, 3.14.9 e 3.13.17](https://blog.python.org/2026/10/python-3151-3149-31317/)
- [Resumo do incidente mantido pela comunidade](https://emudhra.we-have-a-problem.com/)
- [Mozilla: bug 2083449, sobre as chaves da emSign](https://bugzilla.mozilla.org/show_bug.cgi?id=2083449)
- [certifi: GHSA-6q48-6c7w-9gw2](https://github.com/certifi/python-certifi/security/advisories/GHSA-6q48-6c7w-9gw2)