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

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:

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:

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, 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. Se quiser ajuda para revisar ambientes virtuais, imagens e servidores, fale com a gente sobre a gestão de servidores.