Problemas de segurança no Python: riscos comuns e como mitigá-los

Principais conclusões

• Os problemas de segurança do Python decorrem tanto do que você importa quanto do que você escreve.
• O “typosquatting” e a confusão de dependências são formas bem documentadas pelas quais pacotes maliciosos chegam aos usuários do PyPI.
• Quando uma versão do Python chega ao fim de sua vida útil, as correções de segurança do desenvolvedor original deixam de ser disponibilizadas.
• A verificação no CI, as versões fixas das dependências e o hábito constante de aplicar patches eliminam grande parte dos riscos do dia a dia.

Um aplicativo aparentemente seguro pode ser lançado com uma vulnerabilidade conhecida oculta em quatro camadas de dependências, e você nunca a identificaria em seu próprio código-fonte. Seu próprio código pode representar um problema igualmente grave, por meio de deserialização insegura, falhas de injeção ou uma configuração incorreta. O risco de segurança em Python está presente em três lugares ao mesmo tempo: sua cadeia de suprimentos, sua versão de tempo de execução e o código que você mesmo escreveu.

Este artigo aborda as vulnerabilidades que realmente surgem em ambiente de produção, os CVEs que vale a pena conhecer pelo nome e os hábitos que reduzem a exposição a elas.

O que são os problemas de segurança do Python?

Os problemas de segurança do Python são vulnerabilidades ou pontos fracos em aplicativos escritos em Python que um invasor pode explorar para acessar dados, sequestrar funcionalidades ou comprometer a integridade do sistema. O Python é utilizado em praticamente todos os lugares e se baseia em um enorme ecossistema de pacotes de terceiros, e é justamente esse ecossistema que oferece aos invasores uma superfície de ataque tão ampla na cadeia de suprimentos.

A maioria dessas questões não é nada incomum. Elas decorrem de práticas inadequadas de programação, como passar dados inseridos pelo usuário para a função eval(), de bibliotecas desatualizadas com uma vulnerabilidade CVE pública, ou simplesmente de erros de configuração , como o modo de depuração deixado ativado no ambiente de produção.

Há uma quarta causa que pega as equipes de surpresa: a utilização de uma versão do Python que não recebe mais correções. Quando uma versão chega ao fim de sua vida útil, os patches de segurança do desenvolvedor original são interrompidos; portanto, qualquer vulnerabilidade descoberta após essa data permanece sem correção, a menos que você migre para uma versão mais recente ou contrate suporte estendido de outra fonte.

Os termos utilizados pelo próprio Python para esses estados são “bugfix” e “security”. Os ramos “bugfix” recebem tanto correções de bugs quanto correções de segurança e recebem novos binários a cada dois meses. Quando um ramo passa para o estado “security”, apenas correções de segurança são aceitas e não são mais lançados binários, o que pode significar a necessidade de compilar a partir do código-fonte em algumas plataformas e observar que bibliotecas de terceiros começam a interromper o suporte. Considere o início dessa fase como o momento de planejar sua atualização, e não como um motivo para relaxar.

Problemas comuns de segurança no Python

As vulnerabilidades abaixo aparecem tanto em aplicativos web quanto em pipelines de dados e ferramentas internas. Algumas são erros de programação que você pode controlar. Outras surgem por meio de dependências que você nunca escolheu, e essa segunda categoria é a mais fácil de passar despercebida.

O relatório de 2024 da Sonatype sobre a cadeia de suprimentos constatou que 80% das dependências de aplicativos ficam sem atualização por mais de um ano e que, em 95% dos casos em que um componente vulnerável é incorporado, já existe uma versão corrigida. Em muitos casos, o problema nem sequer é uma vulnerabilidade de dia zero. Trata-se de um CVE conhecido, com uma versão corrigida já disponível.

Deserialização insegura

Carregar dados em formato pickle de uma fonte não confiável é um risco iminente de execução remota de código. O `pickle.load()` reconstruirá sem problemas objetos Python arbitrários, incluindo aqueles que executam código no momento em que são instanciados. O mesmo vale para yaml.load() com um carregador inseguro. Para arquivos YAML não confiáveis, use `yaml.safe_load()`e mantenha o pickle totalmente afastado de dados não confiáveis ou não autenticados.

Injeção por meio da execução dinâmica

eval() e exec() transformam strings controladas pelo invasor em código Python executável. O SQL sem parâmetros representa a mesma classe de problema, porém por meio de um mecanismo diferente, no qual a entrada reformula a estrutura de uma consulta, em vez de reformular o programa. Formatar uma consulta com uma f-string em vez de vincular parâmetros é o clássico erro fatal nesse caso. A regra é simples e eficaz: nunca interpolar entradas não confiáveis em código, comandos de shell ou SQL.

Dependências vulneráveis e maliciosas

Um projeto típico envolve uma longa árvore transitiva, e qualquer pacote nessa árvore pode conter um CVE conhecido ou acabar sendo uma imitação direta de algo legítimo. O “typosquatting” e a confusão de dependências são, atualmente, padrões bem documentados na cadeia de suprimentos. O artigo da TuxCare sobre três pacotes do PyPI flagrados executando mineradores no Linux mostra como isso ocorre na prática.

Se você prefere proteção ativa em vez de e-mails informativos, o SecureChain para Python substitui o repositório público do PyPI por uma alternativa verificada e recompilada a partir do código-fonte, que é verificada contra malware e recebe correções continuamente.

Percorrimento de caminhos no manuseio de arquivos

A extração de arquivos apresenta risco de traversal de caminho sempre que os caminhos dos membros não forem tratados com cuidado, pois um nome de membro que contenha ../ pode fazer com que um arquivo seja gravado fora do diretório em que você pretendia gravá-lo. No módulo tarfile do Python, esse problema é registrado como CVE-2007-4559, e permaneceu na biblioteca padrão por bem mais de uma década antes que qualquer mecanismo de filtragem de extração fosse implementado.

Executando o Python em fim de vida útil

Esse não é tanto um bug de código, mas sim um problema de data. Um serviço legado em execução Python 2, muito além do fim de sua vida útil não recebe correções de segurança do desenvolvedor original; portanto, todas as vulnerabilidades CVE aplicáveis permanecem em aberto, a menos que você migre ou obtenha suporte estendido. Quando uma reescrita for viável, a migração do Python 2 para o 3 é a solução definitiva.

Suporte ilimitado ao ciclo de vida do Python pela TuxCare é a solução provisória enquanto isso. Ele garante que os patches CVE continuem sendo fornecidos para o Python 2.7 e para as versões 3.3 a 3.13 assim que essas versões atingirem o fim do ciclo de vida, por meio do gerenciador de pacotes que você já utiliza.

O Python está em toda parte, e isso faz parte do risco

O alcance do Python é exatamente o motivo pelo qual sua dívida de segurança se agrava. Os sistemas desenvolvidos com ele tendem a ter muito código e a suportar grande carga de trabalho, de modo que até mesmo uma pequena alteração pode comprometer as operações, fazendo com que as migrações de versão sejam adiadas para o próximo trimestre. Esses atrasos são um dos principais motivos pelos quais ambientes de execução sem suporte técnico ainda permanecem em produção.

O Django é utilizado por diversos sites de alto tráfego, e o Django 1.11 foi a última versão a oferecer suporte ao Python 2, cujo suporte foi totalmente descontinuado na versão 2.0. O Flask também deixou de oferecer suporte ao Python 2 na versão 2.0. Se um site ainda depende de uma versão da era do Python 2 de qualquer uma dessas estruturas, ele precisa de um caminho de migração compatível ou de outra fonte de correções de segurança.

Na área de IA e aprendizado de máquina, o TensorFlow, o pandas e o scikit-learn oferecem APIs em Python, embora se baseiem fortemente em código otimizado em C, C++ ou Cython. Uma vulnerabilidade nessas bibliotecas, amplamente utilizadas, pode afetar um grande número de aplicativos derivados.

No âmbito do DevOps, o Ansible, o Mercurial, o Buildbot e o SCons são escritos em Python ou estão fortemente integrados a ele; já no âmbito corporativo, plataformas como o Tryton e o Odoo operam grandes implantações, nas quais o tempo de inatividade se torna rapidamente oneroso.

Melhores práticas para proteger aplicativos em Python

Você não precisa de uma equipe de segurança dedicada para resolver grande parte disso. O que você precisa é de alguns hábitos aplicados automaticamente, para que nada dependa da memória de uma pessoa. O objetivo é a prevenção, ou seja, garantir que código defeituoso não seja lançado, além de uma correção rápida para os casos em que algo acabe passando despercebido.

Fixar e auditar suas dependências

Fixar as versões das dependências no arquivo requirements.txtou use o arquivo de bloqueio do seu gerenciador de pacotes, para que a resolução ocorra sempre da mesma maneira. Em seguida, verifique esse arquivo a cada commit.

Ferramentas como o pip-audit e o Safety CLI verificam suas dependências em bancos de dados de vulnerabilidades e retornam um valor diferente de zero quando encontram uma correspondência, o que faz com que uma tarefa de CI falhe ao detectar uma vulnerabilidade. Vale a pena saber que o antigo comando `check` do Safety foi descontinuado em favor do safety scan.

Dica profissional: O `pip-audit` já retorna um código de saída diferente de zero quando encontra uma vulnerabilidade; portanto, o comando `pip-audit -r requirements.txt` é suficiente para que a CI reprova a tarefa, em vez de permitir que o problema chegue à produção. Adicione –strict quando você também quiser que falhas na coleta de dependências façam com que a auditoria seja reprovada.

Validar e sanitizar todas as entradas

Trate toda entrada externa como não confiável por padrão, sejam campos de formulário, cargas de API, uploads de arquivos ou conteúdos de arquivos compactados. Utilize consultas parametrizadas para bancos de dados, listas de permissões para caminhos de arquivos e carregadores seguros para dados serializados, o que, na prática, significa yaml.safe_load() e nunca descompactar dados não confiáveis ou não autenticados.

Executar análise estática

A análise estática identifica padrões perigosos antes que o código seja lançado. O Bandit é uma ferramenta de análise estática amplamente utilizada e voltada para Python, que sinaliza itens como senhas codificadas, o uso de `assert` para verificações de segurança e chamadas inseguras a subprocessos. Execute-o junto com seu linter para que as verificações de segurança se tornem parte do ciclo normal de desenvolvimento, em vez de uma tarefa separada.

Mantenha o Python e suas bibliotecas atualizados

Pacotes desatualizados são um motivo comum para que uma vulnerabilidade conhecida continue sujeita a exploração. Uma rotina disciplinada de aplicação de patches, abrangendo o ambiente de execução, a biblioteca padrão e suas dependências, reduz a janela de oportunidade da qual os invasores se valem. Se a linha divisória entre a correção de vulnerabilidades e o monitoramento de riscos parecer pouco clara, esta análise comparativa entre gerenciamento de patches versus gerenciamento de vulnerabilidades vale a pena ser lida.

Aplicar o princípio do privilégio mínimo em tempo de execução

Execute os serviços como um usuário que não seja o root, defina permissões de arquivo e de rede de forma restrita e nunca lance uma versão com o modo de depuração ativado. Se um invasor conseguir executar código, o princípio do privilégio mínimo é o que determinará se você terá um incidente controlável ou uma semana muito ruim.

Como mitigar os riscos de segurança do Python

As melhores práticas mostram como deve ser o trabalho bem feito. A mitigação é a ordem em que você lida com as tarefas quando há um acúmulo real de trabalho e tempo insuficiente. Trabalhe da tarefa de maior impacto para a de menor impacto.

Passo 1: Faça um inventário do que você realmente utiliza

Não é possível proteger o que não se vê. Gere uma lista de componentes de software para ter uma lista completa das dependências diretas e transitivas, além da versão exata do Python em cada ambiente.

Etapa 2: Verificação em relação a CVEs conhecidos

Insira esse inventário em um scanner — seja o pip-audit, o Safety CLI ou uma ferramenta de plataforma — e compare cada pacote instalado e sua versão com os alertas de vulnerabilidade conhecidos. Isso transforma a ideia de “talvez tenhamos problemas” em uma lista classificada e corrigível.

Atenção: Um inventário que capture apenas suas necessidades diretas pode deixar vulnerabilidades transitivas fora do campo de visão. Verifique se sua ferramenta resolve ou registra toda a árvore de dependências antes de confiar nos resultados.

Etapa 3: Priorize com base na explorabilidade, e não apenas na gravidade

Uma pontuação CVSS alta em um código que não está acessível em sua implantação não supera automaticamente um bug de gravidade média exposto por meio de uma API voltada para o público. Interprete a gravidade dentro do contexto, levando em conta a acessibilidade e as evidências de exploração ativa. Este guia introdutório sobre como funcionam as pontuações CVE e CVSS ajuda você a priorizar a triagem em vez de aplicar correções às cegas.

Etapa 4: Aplicar o patch e, em seguida, verificar

Aplique a correção e, em seguida, confirme se ela realmente foi aplicada. Execute novamente o scanner e seu conjunto de testes. A mesma disciplina se aplica a toda a pilha, desde uma dependência do Python até os pacotes do Linux subjacentes, pois aplicar correções sem verificação é apenas otimismo.

Passo 5: Automatize para que a correção seja permanente

A aplicação manual de patches perde a eficácia assim que as pessoas ficam ocupadas. Programe verificações recorrentes, ative pull requests automáticos para atualização de dependências e condicione as fusões à aprovação de uma verificação de segurança sem falhas. A aplicação de patches funciona como um pipeline, não como um exercício de emergência trimestral.

Vulnerabilidades comuns de segurança do Python (CVEs)

Trata-se de CVEs reais, atribuídos na biblioteca padrão ou em pacotes amplamente utilizados. Dois deles estão no setuptools – as ferramentas de compilação são um ponto cego recorrente que as equipes se esquecem de verificar. As pontuações abaixo são do NVD CVSS v3.1, e as classificações do desenvolvedor original ou do fornecedor para o mesmo CVE às vezes diferem; portanto, não se surpreenda se o seu scanner mostrar um número diferente.

Traversal de caminho em arquivo tar (CVE-2007-4559)

Uma vulnerabilidade de traversal de diretório no tarfile.extract() e extractall() permite que um arquivo compactado malicioso grave arquivos fora do diretório de destino usando .. nos nomes dos membros. A Trellix trouxe a questão de volta à tona no setor em 2022, estimando mais de 350.000 repositórios de código aberto vulneráveis a partir de uma taxa de 61% encontrada em uma amostra manual de seus resultados de varredura. O Python 3.12 adicionou filtros de extração por meio da PEP 706. Nas versões 3.12 e 3.13, o comportamento legado ainda é o padrão e um DeprecationWarning é disparado quando nenhum filtro é passado; portanto, o código precisa passar filter=’data’ ou outro filtro apropriado para obter um tratamento mais seguro. O Python 3.14 torna data como padrão.

A configuração padrão mais segura ajuda, mas não elimina totalmente o risco de extração de arquivos. Um lote de versões do CPython lançadas em junho de 2025, incluindo as versões 3.9.23, 3.10.18, 3.11.13, 3.12.11 e 3.13.4, corrigiu várias formas pelas quais o dados e tar pudessem ser contornados por meio de links simbólicos e links físicos criados propositalmente, registrados como CVE-2024-12718, CVE-2025-4138, CVE-2025-4330, CVE-2025-4435 e CVE-2025-4517. A própria documentação do tarfile do Python ainda alerta que nenhum filtro bloqueia todos os recursos perigosos de arquivos compactados; portanto, trate os filtros como uma camada de proteção, mantenha sua versão pontual atualizada e verifique os arquivos e caminhos criados durante a extração.

Digno de nota: quando a falha foi relatada pela primeira vez em 2007, a medida de mitigação imediata foi um aviso na documentação, em vez de uma alteração no comportamento da extração. A configuração padrão mais segura só chegou com o Python 3.14, cerca de dezoito anos após o problema ter sido relatado pela primeira vez.

Contornamento da lista de bloqueio no urllib.parse (CVE-2023-24329)

Uma URL que comece com determinados caracteres em branco pode passar despercebida pelas verificações da lista de bloqueio baseadas em urllib.parse, pois o analisador não remove esses caracteres iniciais antes da validação. Qualquer proteção contra SSRF ou filtro de URL que dependa dessa análise afetada pode ser comprometido por isso. Corrigido no Python 3.11.4, com retroportações para as versões 3.10.12, 3.9.17, 3.8.17 e 3.7.17.

Execução remota de código no setuptools (CVE-2024-6345)

O package_index auxiliares de download do setuptools até a versão 69.1.1 criam comandos de shell com os.system() ao buscar URLs do Git e do Mercurial; assim, uma URL de pacote controlada por um invasor pode resultar na execução de um comando. Corrigido no setuptools 70.0. A maioria das equipes nem sequer pensa em fixar ou escanear o próprio setuptools, pois as ferramentas de compilação são discretamente classificadas como infraestrutura, em vez de dependências.

Execução de código arbitrário no Pillow (CVE-2023-50447)

O Pillow, até a versão 10.1.0, permite a execução de código arbitrário por meio do parâmetro de ambiente de PIL.ImageMath.eval(). A vulnerabilidade depende de valores controlados pelo invasor que cheguem a esse parâmetro, e não simplesmente do processamento de imagens fornecidas pelo usuário. Corrigida no Pillow 10.2.0, que restringe o que o ambiente de avaliação pode acessar.

Traversal de caminho no setuptools (CVE-2025-47273)

A segunda falha do setuptools é uma traversal de caminho em PackageIndex.download. O caminho de destino é construído com os.path.join(), que descarta o diretório temporário quando o nome do arquivo manipulado pelo invasor começa com uma barra ou uma letra de unidade; assim, os arquivos podem ser gravados em qualquer local onde o processo em execução tenha permissão, levando à execução de código, dependendo do contexto. Corrigido no setuptools 78.1.1. Tanto o easy_install e package_index estão obsoletos, o que reduz a exposição, mas duas falhas na mesma ferramenta de compilação em um ano são um bom lembrete para verificar sua cadeia de ferramentas e não apenas suas dependências de tempo de execução.

Mantenha suas aplicações em Python seguras com a TuxCare

A parte difícil da segurança em Python não é conhecer as correções. É manter o ambiente de execução, a biblioteca padrão e suas dependências atualizadas, sem forçar uma migração imediata ou uma atualização disruptiva do aplicativo. Essa lacuna se amplia no momento em que uma versão chega ao fim de vida útil e os patches do desenvolvedor original deixam de ser fornecidos.

O TuxCare aborda os dois aspectos desse problema.

Para equipes que se encontram em um dilema entre “precisamos atualizar” e “não podemos interromper a produção neste momento”, o Suporte de Ciclo de Vida Ilimitado para Python oferece patches de segurança contínuos para o Python 2.7 e as versões 3.3 a 3.13 após o fim de vida útil, pelo tempo que você precisar. Sem prazo de migração obrigatório – a aplicação de patches para vulnerabilidades CVE simplesmente continua após o término do suporte do desenvolvedor original.

Para equipes preocupadas com o que está sendo instalado via pip, o SecureChain para Python substitui o repositório público do PyPI por uma alternativa verificada e recompilada a partir do código-fonte. Os pacotes passam por uma verificação contra malware antes de chegarem ao seu ambiente, e a aplicação de patches continua muito depois que os mantenedores originais param. Os mesmos pacotes, o mesmo fluxo de trabalho, sem a confiança cega.

Resumo

Nome do artigo

Problemas de segurança no Python: riscos comuns e como mitigá-los

Descrição

Conheça os problemas de segurança mais comuns do Python, seus riscos e as melhores práticas para proteger suas aplicações e sistemas em Python.

Autor

Rohan Timalsina

Nome da editora

TuxCare

Logotipo da editora