Em 26 de outubro de 2026 o blog do Python anunciou releases de segurança emergenciais para 3.15, 3.14, 3.13, 3.12 e 3.11. Elas bloqueiam no módulo ssl chaves comprometidas de CA intermediária da eMudhra e corrigem um bypass do tarfile.tar_filter, contraparte do CVE-2026-7774 no data_filter. O time de release recomenda atualizar todas as versões afetadas, inclusive 3.11 e 3.12.
Por que o Python lançou patches para cinco versões ao mesmo tempo?
O gatilho foi o comprometimento de chaves de CA intermediária da eMudhra. A correção entrou em todos os branches suportados de uma vez, como 3.15.2, 3.14.10, 3.13.18, 3.12.16 e 3.11.18. O post do Python Insider é de 26 de outubro de 2026 e foi assinado por Hugo van Kemenade. Já a página de download do 3.12.16 traz 25 de outubro de 2026 como data de release.
O módulo ssl agora bloqueia essas chaves como último recurso contra o uso delas. O anúncio de segurança de 24 de outubro de 2026 descreve o mecanismo. O Python adicionou ao ssl uma denylist de certificados sabidamente comprometidos. Certificado que está nessa lista é rejeitado automaticamente, seja qual for a política configurada no SSLContext. O objetivo declarado é proteger o usuário mesmo onde ninguém configurou revogação de certificados.
Isso mexe também com a instalação de pacotes. Segundo o post da release, o uso normal do pip, inclusive para atualizar o próprio pip, fica protegido contra ataques baseados nessas chaves. Isso vale mesmo que o pip ainda não tenha sido atualizado. A proteção mora no interpretador. Então a versão que importa é a do Python que executa o pip.
Quais vulnerabilidades as novas versões do Python corrigem?
As cinco releases corrigem o CVE-2026-115557, o CVE-2026-114583 e uma falha no http.cookiejar. O primeiro trata da remoção da confiança nas chaves comprometidas de CA intermediária da eMudhra. O segundo fecha um bypass do tarfile.tar_filter. A correção do http.cookiejar faz o módulo rejeitar cookies com versão negativa.
A falha do tarfile foi anunciada em 22 de outubro de 2026 como vulnerabilidade de severidade MEDIUM no CPython. Entradas de link manipuladas, incluindo symlinks com nome vazio ou com cara de diretório, podiam desviar os membros seguintes do arquivo para fora do diretório de extração. Com isso, um tar malicioso podia fazer o tarfile.extractall() com filter=“tar” gravar arquivos fora do destino. O limite era a permissão do processo que fazia a extração. O anúncio trata o caso como a contraparte, no tar_filter, do CVE-2026-7774, que afetava o tarfile.data_filter.
Os branches mais antigos ainda recebem correções que os mais novos já tinham.
| Versão | Fase do branch | Distribuição | Correções além das três comuns |
|---|---|---|---|
| 3.15.2 | bugfix | Instaladores binários | Só as comuns |
| 3.14.10 | bugfix | Instaladores binários | Só as comuns |
| 3.13.18 | security | Só código-fonte | Expat 2.9.0, mimetypes no Windows, caso de borda no refolding de headers, race condition na limpeza do tempfile.TemporaryDirectory |
| 3.12.16 | security | Só código-fonte | Igual ao 3.13.18 |
| 3.11.18 | security | Só código-fonte | Expat 2.9.0, mimetypes no Windows, caso de borda no refolding de headers |
As correções extras do 3.13, 3.12 e 3.11 já estavam no 3.15.1 e no 3.14.9. A do tempfile já estava no 3.15.0 e no 3.14.9.
Preciso reconstruir as imagens com Python 3.11 e 3.12 esta semana?
Sim, se você seguir a orientação do próprio time de release. Ele recomenda fortemente a atualização para todos os usuários de versões afetadas. O 3.11 e o 3.12 receberam as três correções comuns e também os backports da tabela.
O detalhe está no empacotamento. O 3.13.18, o 3.12.16 e o 3.11.18 saíram só como código-fonte, enquanto 3.15.2 e 3.14.10 vêm com instaladores binários. A página do 3.12.16 diz que o branch só recebe correções de segurança, em releases irregulares e só de código-fonte até outubro de 2028. Instalador binário para o 3.12 não sai mais. O guia de desenvolvimento coloca o 3.11 na mesma fase de security.
Para um time de plataforma, isso divide a frota em dois grupos. Imagem que compila o CPython a partir do tarball recebe a correção trocando a versão e fazendo rebuild. Imagem que pega o Python de um pacote do sistema operacional depende de a distribuição publicar a própria correção.
O tracker de segurança do Debian mostra por que esse segundo grupo pede verificação própria. Na entrada do CVE do tarfile, o python3.11 do bookworm aparece como vulnerável, inclusive na suíte de segurança. O python3.13 do trixie, o pypy3 e o jython também constam como vulneráveis. Só o python3.14 3.14.10-1 e o python3.15 3.15.2-1 do sid aparecem como corrigidos. No trixie, o tracker ainda classifica python3.13 e pypy3 como minor issue, sem DSA. Para esse CVE do tarfile, o tracker ainda não lista versão corrigida do python3.11 no bookworm nem do python3.13 no trixie. E interpretadores alternativos também entram no inventário.
O guia de desenvolvimento lista o Python 3.10 como end-of-life. Ele ficou fora dos branches suportados.
Como pesar o risco de cada correção
A correção da eMudhra tem o alcance maior. Ela vale para tudo que usa o módulo ssl, de clientes entre serviços até pip install dentro do pipeline de build. Uma imagem com interpretador antigo continua validando certificados sem essa denylist.
A do tarfile pesa mais onde o código extrai arquivos que não criou usando o filtro tar. Pense em upload de usuário, artefato baixado da internet ou pacote de plugin. A dos cookies atinge clientes HTTP montados sobre o http.cookiejar. O Expat embutido sobe para 2.9.0 no 3.13, no 3.12 e no 3.11. A mudança do mimetypes só vale para Windows.
O que verificar esta semana
O prazo razoável vai até o fim da sexta-feira, 30 de outubro de 2026.
Até quinta, levante cada imagem base e cada runtime com a versão exata de patch do Python. Inclua runners de CI e imagens de build que rodam pip. Qualquer coisa abaixo de 3.15.2, 3.14.10, 3.13.18, 3.12.16 ou 3.11.18 é candidata a rebuild.
Depois classifique cada imagem pela origem do Python. Quem compila do código-fonte já pode usar os tarballs novos. Quem usa pacote de distribuição precisa acompanhar o tracker daquele fornecedor, como o do Debian.
Em paralelo, procure no código chamadas de tarfile.extractall() com filtro tar sobre arquivos vindos de fora. Esses caminhos ficam com a exposição mais direta até o rebuild chegar em produção.
Na sexta, faça rebuild e deploy das imagens compiladas do fonte. Em seguida confirme a versão do interpretador dentro de um container rodando. Toda imagem que ficar presa a pacote de distribuição ganha um dono e uma data amarrada à correção do fornecedor. Serviço que ainda roda 3.10 precisa de um plano de migração, porque essa versão está fora dos branches suportados.
Fontes
- blog.python.org/2026/10/python-3152-31410-31318-31216-31118, consultada em 28 de outubro de 2026.
- python.org/downloads/release/python-31216, consultada em 28 de outubro de 2026.
- openwall.com/lists/oss-security/2026/10/24/5, consultada em 28 de outubro de 2026.
- openwall.com/lists/oss-security/2026/10/22/33, consultada em 28 de outubro de 2026.
- security-tracker.debian.org/tracker/CVE-2026-114583, consultada em 28 de outubro de 2026.
- devguide.python.org/versions, consultada em 28 de outubro de 2026.