luigigubello/cve-2025-64512-polyglot-pocUma Prova de Conceito para CVE-2025-64512 usando um arquivo poliglota.
Nas últimas semanas (em novembro de 2025), uma vulnerabilidade interessante (CVE-2025-64512) foi divulgada no pdfminer.six, um popular projeto Python para processar arquivos PDF, usado em particular em pipelines de IA. A vulnerabilidade permite execução remota de código através da desserialização de dados não confiáveis via pickle.loads(), utilizando um arquivo PDF como vetor de ataque. Até aí, tudo bem: é uma vulnerabilidade importante em um pacote Python popular. O que chamou minha atenção foi a explorabilidade 👀.
Em sistemas do tipo Linux, apenas arquivos no sistema de arquivos podem ser resolvidos. Um atacante precisaria fornecer o PDF malicioso para processamento e o arquivo pickle malicioso precisaria estar presente no sistema alvo em um local que o atacante já conheça, pois precisa ser definido no próprio PDF. Em muitos casos, isso será difícil de explorar porque, mesmo que o atacante forneça tanto o PDF quanto o arquivo pickle juntos, não haveria como saber antecipadamente qual caminho completo para o arquivo pickle especificar. [...] No geral, há menos risco em um sistema Linux ou similar a Linux.
Então, aparentemente, para explorar essa vulnerabilidade em um sistema do tipo Linux, o atacante deve:
Podemos criar um arquivo PDF válido que acione a vulnerabilidade sem saber o caminho do arquivo pickle malicioso?
"Válido" significa que o pdfminer.six não recusa o arquivo e começa a processá-lo (porque um arquivo PDF é o que um leitor de PDF abre).
A resposta é Sim, criando um polyglot payload (uma espécie de). A ideia é criar um arquivo que seja ao mesmo tempo um pickle.gz válido e um arquivo PDF válido, para que o pdf2txt.py possa começar a processar um arquivo PDF e, em seguida, apontar para ele para carregar o código pickle em formato GZIP.
Frequentemente - mas nem sempre 🥲 - um arquivo é um arquivo PDF se tiver %PDF- em algum lugar, geralmente nos primeiros 1024 bytes (1 - 2). Para o pdfminer.six, um arquivo PDF válido apenas precisa ter um objeto /Root (pdfdocument.py#L752).
Um arquivo GZIP tem bytes iniciais específicos (RFC 1952 - Sec. 2.3.1), mas suporta comentários (FCOMMENT, RFC 1952 - Sec. 2.3.1).
Então, este é o design do arquivo polyglot: criar um GZIP válido contendo o payload pickle malicioso e incorporar um arquivo PDF válido no flag FCOMMENT do GZIP. Em seguida, usar este arquivo como um PDF válido com o pdf2txt.py para acionar a vulnerabilidade e usar o mesmo arquivo para executar o pickle malicioso.
(2025.12.12) EDITAR:
A única restrição que temos é o nome do arquivo: ele deve terminar com .pickle.gz (isso está embutido no código do pdfminer.six, cmapdb.py#L235).
As duas restrições que temos são:
pdfminer.six, cmapdb.py#L235);Estou um pouco surpreso que esta CVE seja tão subestimada, considerando a popularidade deste projeto (6k ⭐️ no GitHub, mas usado por 34k projetos, de acordo com as estatísticas do GitHub) e os casos de uso (ferramentas de linha de comando, fluxos de trabalho de IA, pipelines, em suma, todos os tipos de infraestrutura que você não quer atualizar se estiver funcionando bem).
Por exemplo, a ferramenta da Microsoft markitdown 0.1.3 (microsoft/markitdown, 84k ⭐️ no GitHub e usado por 2k projetos), instalada antes de 1º de dezembro, está vulnerável a execução arbitrária de código via pdfminer.six. A equipe da Microsoft lançou um patch em 1º de dezembro, 0.1.4, mas sem alertas de segurança, então acho que a atualização não foi priorizada por outras equipes de engenharia.
Outros projetos podem ser afetados pelo CVE-2025-64512, e é bem fácil de explorar.
Uma lista (incompleta) de projetos vulneráveis:
docker build -t cve-2025-64512-poc .
docker run --rm -it cve-2025-64512-poc
pdf2txt.py payload.pickle.gz
docker build -t cve-2025-64512-poc .
docker run --rm -it cve-2025-64512-poc
markitdown markitdown-payload.pickle.gz -x pdf -o output.md
