O que aconteceu e o que é PYSEC-2025-19

O registro PYSEC-2025-19 descreve uma falha no picklescan, uma ferramenta usada para verificar arquivos de modelos que podem conter dados serializados com Pickle. O problema afetava versões anteriores à 0.0.22. Segundo o registro mantido pelo OSV, o problema foi publicado em 3 de março de 2025 e recebeu atualização em 9 de julho de 2026. O mesmo caso aparece associado aos identificadores CVE-2025-1716, CVE-2025-1889, GHSA-655q-fx9r-782v e GHSA-769v-p64c-89pr.

A falha não significa que todo arquivo verificado pelo picklescan estivesse comprometido. O ponto é mais específico: antes da correção, a ferramenta considerava apenas extensões de arquivo normalmente usadas para Pickle ao definir o escopo da análise. Um atacante poderia colocar um arquivo Pickle malicioso dentro de um modelo e usar uma extensão não padrão. Como esse arquivo ficaria fora do escopo reconhecido, o modelo poderia passar por uma verificação que aparentasse estar concluída.

O caso é importante porque mostra que a extensão do arquivo não pode ser tratada como prova do formato real nem como controle de segurança. Pipelines de inteligência artificial dependem de repositórios, caches, registries, automações de CI e scripts de carregamento. Uma falha em qualquer uma dessas etapas pode transformar uma checagem aparentemente útil em uma barreira incompleta.

Como funciona o problema

Pickle é um mecanismo de serialização do ecossistema Python. Ele pode representar estruturas complexas e objetos de uma aplicação, mas o processo de desserialização de dados não confiáveis exige cuidado. Dependendo do conteúdo e da forma como o objeto é carregado, a desserialização pode executar comportamentos definidos pelo próprio arquivo. Por isso, um arquivo de modelo não deve ser considerado seguro apenas porque veio de um repositório conhecido ou porque tem um nome familiar.

O picklescan tenta ajudar nessa avaliação procurando construções perigosas em arquivos Pickle. A falha registrada no PYSEC-2025-19 estava na definição do que deveria ser examinado. O scanner reconhecia extensões padrão, mas podia deixar passar um Pickle com outro sufixo. Na prática, o atacante não precisava necessariamente vencer a análise de cada instrução detectada. Bastava esconder o arquivo em uma forma que a etapa de descoberta não incluísse.

Esse cenário pode ocorrer em um pacote compactado, em um diretório de pesos de um modelo ou em um artefato baixado por uma rotina automática. Se a verificação examina somente nomes e extensões, o arquivo fica invisível para aquela etapa. Depois, uma aplicação ou biblioteca pode encontrá-lo por outro caminho e tentar carregá-lo. O problema, portanto, envolve a diferença entre o escopo da inspeção e o conjunto real de arquivos que será usado em produção.

Quem foi afetado e para que serve a ferramenta

O risco alcança equipes que usam picklescan para avaliar modelos de aprendizado de máquina, pacotes Python ou artefatos recebidos de terceiros. Isso inclui pipelines que baixam modelos de registries públicos, processos de revisão de pull requests, estações de pesquisa e ambientes de inferência que armazenam modelos em objetos compactados. A presença da ferramenta é um sinal positivo de maturidade, mas ela deve fazer parte de uma defesa em camadas.

O registro não apresenta uma contagem de vítimas nem confirma um incidente específico causado por essa falha. A consequência demonstrada é a possibilidade de um arquivo malicioso escapar da análise quando a extensão não está no conjunto considerado pelo scanner. Essa distinção é importante: existe uma condição de bypass documentada, mas não se deve transformar isso em alegação de vazamento ou invasão sem evidência do ambiente analisado.

Para gestores de plataformas de IA, a pergunta prática é quais arquivos serão realmente carregados. Para desenvolvedores, é necessário saber se o código abre todos os arquivos de um diretório, se descompacta artefatos automaticamente e se aceita dados Pickle de fontes externas. Para equipes de segurança, o inventário precisa cobrir o conteúdo e o comportamento do pipeline, e não apenas a lista de extensões permitidas.

Como identificar a exposição

O primeiro passo é descobrir qual versão do picklescan está instalada em cada ambiente. O OSV informa que a correção está na versão 0.0.22, enquanto as versões anteriores listadas como afetadas incluem as releases de 0.0.1 a 0.0.21. A verificação deve incluir ambientes de desenvolvimento, runners de CI, imagens de contêiner, notebooks e jobs de produção. Uma versão corrigida em um servidor não protege automaticamente um pipeline que ainda executa a versão antiga.

Em seguida, faça um inventário do conteúdo dos modelos e dos pacotes. Liste arquivos dentro de tarballs, zip e outros formatos aceitos pela cadeia de entrega. Compare essa lista com o que o scanner reporta. Diferenças entre a descoberta feita pelo pipeline e a descoberta feita por uma inspeção independente são um sinal de que a cobertura precisa ser revisada.

Também vale procurar por arquivos cujo conteúdo começa ou se comporta como Pickle, mas cujo nome não usa a extensão esperada. Essa análise deve ocorrer em uma cópia isolada e sem desserializar os objetos. Não execute o arquivo suspeito para descobrir o que ele faz. Registre o caminho, o hash, a origem, o repositório, o commit e o responsável pela aprovação. Esses dados ajudam a diferenciar um artefato legítimo de uma alteração introduzida na cadeia de suprimentos.

Por fim, revise os logs da etapa de verificação. Um resultado positivo ou seguro precisa informar quais arquivos foram analisados e quais foram ignorados. Se o log registra somente o nome do modelo principal, sem detalhar arquivos internos, a equipe não consegue demonstrar que o conteúdo inteiro foi coberto.

Como se proteger e mitigar

A correção mais direta é atualizar o picklescan para a versão 0.0.22 ou posterior e repetir a verificação dos artefatos existentes. A atualização deve ser aplicada com controle de dependências, registro de versão e validação no pipeline. Depois de corrigir a ferramenta, não basta verificar modelos novos. Reavalie os artefatos que foram aprovados enquanto a versão vulnerável estava em uso, priorizando os que vieram de fontes externas.

A segunda medida é tratar a extensão como um metadado auxiliar, nunca como a única forma de definir o escopo. A etapa de segurança deve enumerar o conteúdo real dos pacotes, inspecionar formatos conhecidos e sinalizar arquivos cujo conteúdo não combina com o nome. Quando não for possível reconhecer um formato com segurança, o pipeline deve interromper a aprovação ou encaminhar o artefato para uma análise isolada.

A terceira medida é reduzir o impacto de uma eventual falha de detecção. Carregadores de modelos devem preferir formatos e bibliotecas que não executem código durante a leitura, quando o caso de uso permitir. Ambientes que precisam abrir Pickle devem ficar isolados, sem credenciais desnecessárias, com acesso de rede mínimo, sistema de arquivos temporário e permissões limitadas. Assinaturas, hashes e aprovação de origem também ajudam, mas não substituem a análise do conteúdo.

Por último, mantenha uma trilha de auditoria. Registre o hash do artefato aprovado, a versão do scanner, as regras usadas, o resultado da inspeção e a identidade que autorizou a promoção para produção. Isso facilita a resposta caso uma nova falha seja descoberta e evita que a organização precise reconstruir o histórico manualmente.

Comparação com alternativas anteriores

Uma abordagem baseada apenas em extensões é rápida e simples, mas falha quando o conteúdo é renomeado. Ela pode ser útil para organizar a busca, porém não deve ser a barreira final. A inspeção por assinatura de conteúdo é mais abrangente, embora exija cuidado com arquivos corrompidos, formatos compostos e recursos que podem consumir muita memória ou CPU.

Outra comparação importante é entre análise estática e execução isolada. Um scanner estático procura padrões perigosos sem executar o modelo, o que reduz o risco para o ambiente de análise. Uma sandbox pode observar comportamentos durante o carregamento, mas exige controles fortes para evitar fuga, acesso a segredos ou conexões externas. As duas técnicas cobrem riscos diferentes e podem ser combinadas conforme o nível de exposição do pipeline.

Há também uma diferença entre verificar o pacote recebido e verificar o artefato que será usado. Um registry pode entregar um arquivo compactado, enquanto o job de inferência descompacta e busca um nome específico em uma subpasta. A decisão de segurança precisa acompanhar essa transformação. Um resultado seguro antes da extração não é suficiente se o processo posterior cria novos caminhos de carregamento.

Análise técnica de CVE e versões

O OSV associa PYSEC-2025-19 a dois identificadores CVE, incluindo CVE-2025-1889, e registra o pacote picklescan no ecossistema PyPI. A faixa afetada indicada começa em 0 e tem como evento de correção a versão 0.0.22. A lista de versões afetadas inclui 0.0.1 até 0.0.21. Ao planejar a atualização, confirme a versão resolvida pelo gerenciador de dependências e não apenas a versão declarada em um arquivo de requisitos.

O registro também informa o vetor CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Em linguagem operacional, o vetor descreve exploração pela rede, baixa complexidade, sem privilégio ou interação do usuário, com possível impacto alto em confidencialidade, integridade e disponibilidade dentro do escopo avaliado. O vetor não prova que cada ambiente terá esse resultado. A explorabilidade depende de o artefato chegar ao carregador vulnerável e de o processo permitir a desserialização.

O detalhe técnico central é a falta de cobertura de arquivos Pickle com extensões não padrão. O conserto deve ser validado por testes que incluam nomes de arquivos convencionais e nomes alternativos dentro dos mesmos artefatos. O teste de regressão precisa confirmar que os dois grupos são descobertos e que uma análise concluída não omite silenciosamente arquivos internos.

Impacto e consequências

O impacto mais imediato é a falsa sensação de segurança. Um time pode aprovar um modelo porque o relatório do scanner não apresenta alertas, embora uma parte do conteúdo não tenha sido examinada. Se esse modelo for distribuído ou armazenado em um repositório confiável, a aprovação pode ampliar a exposição para outros ambientes.

O impacto técnico mais grave é condicional: se um arquivo Pickle malicioso escapar e for desserializado por um processo vulnerável, o comportamento do payload pode afetar dados, credenciais, processos e disponibilidade. O artigo não atribui uma consequência concreta a um ambiente específico. A avaliação deve considerar quais permissões o carregador possui, em qual rede ele roda e quais segredos estão disponíveis no momento da operação.

Também há consequências de governança. Um pipeline sem lista de arquivos analisados tem dificuldade para demonstrar diligência em uma investigação. Em setores regulados, a falta de rastreabilidade pode aumentar o custo de resposta e de auditoria. A mitigação técnica, portanto, deve vir acompanhada de evidências verificáveis, política de origem e revisão de dependências.

Dicas práticas e boas práticas

Use este checklist ao revisar pipelines que aceitam modelos ou artefatos Python:

  1. Atualize o picklescan para 0.0.22 ou posterior em todos os ambientes.
  2. Gere um inventário recursivo dos arquivos antes e depois da extração de pacotes.
  3. Compare a lista descoberta pelo pipeline com a lista registrada no relatório de segurança.
  4. Não trate extensão, nome, repositório ou popularidade como prova de segurança.
  5. Verifique hashes, origem, commit, assinatura e aprovação antes de promover um modelo.
  6. Evite desserializar Pickle recebido de terceiros; prefira formatos com leitura sem execução quando possível.
  7. Execute cargas inevitáveis em ambiente isolado, sem credenciais e com rede restrita.
  8. Faça revarredura de artefatos aprovados durante o período em que a versão vulnerável estava instalada.
  9. Preserve logs da versão da ferramenta, regras, arquivos analisados e decisão final.
  10. Crie um teste de regressão com arquivo Pickle de extensão não padrão em cada pipeline.

O checklist deve ser aplicado como parte do processo de entrega, e não somente depois de uma notícia de vulnerabilidade. A repetição é o que transforma uma recomendação em controle operacional.

Conclusão: o que fazer agora

PYSEC-2025-19 é um lembrete de que uma ferramenta de segurança também precisa ser testada contra as formas como um atacante pode esconder o conteúdo. O problema do picklescan anterior à 0.0.22 não estava em um detalhe visual do nome do modelo, mas na diferença entre a lista de extensões reconhecidas e o conjunto real de arquivos que poderia ser carregado.

Atualize a dependência, reavalie os modelos já aprovados e confirme que o relatório identifica todos os arquivos relevantes. Depois, complemente a inspeção com isolamento, controle de origem, hashes e carregadores mais seguros. Se o pipeline não consegue explicar exatamente o que analisou, ele ainda não oferece uma garantia suficiente para artefatos de IA.

Para acompanhar os identificadores e referências do caso, use as fontes oficiais listadas abaixo. A consulta deve fazer parte da rotina de gestão de vulnerabilidades, especialmente quando uma dependência é usada para validar conteúdo que será executado ou desserializado em produção.