Uma vulnerabilidade crítica no Ghostscript, programa amplamente usado para transformar PDFs enviados em miniaturas de imagem em servidores, foi identificada pela Wordfence Threat Intelligence por meio da ferramenta Wordfence Argus. A falha foi reportada à Artifex, mantenedora do software, dezesseis dias antes do lançamento da correção. Em 8 de setembro de 2026, a Artifex publicou o Ghostscript 10.08.0, versão que fecha a brecha catalogada como CVE-2026-39919, com pontuação CVSS de 9,8 de 10 — classificação considerada crítica. O problema é um estouro de buffer na heap: um PDF malicioso contendo uma imagem JPEG 2000 pode fazer o Ghostscript gravar bytes controlados pelo atacante além do limite de um bloco de memória. A equipe conseguiu transformar essa corrupção em execução remota de código não autenticada em um site WordPress criado especificamente para testes.
Quem administra sites em WordPress deve ficar atento a um detalhe importante: não existe plugin para atualizar nesse caso. O Ghostscript é fornecido pelo sistema operacional ou pela imagem do contêiner, portanto a correção geralmente chega por meio da distribuição Linux usada ou do provedor de hospedagem. Sites que rodam em contêineres precisam ser reconstruídos a partir de uma imagem-base atualizada. Dez ambientes de pacotes Linux foram testados em 15 de setembro, e a própria imagem oficial do Docker para WordPress analisada estava entre as vulneráveis.
O que é o Ghostscript e qual sua relação com o WordPress
O Ghostscript é um motor de processamento de documentos: ele lê arquivos PDF e PostScript e converte suas páginas em imagens que outros programas conseguem exibir, imprimir ou pré-visualizar. Por rodar por trás de diversas aplicações que nunca mencionam seu nome diretamente, muitos administradores de servidores o utilizam sem saber disso.
O WordPress, por si só, não gera prévias de PDF. Desde a versão 4.7, o núcleo do sistema é capaz de criar uma imagem da primeira página de um PDF ao gerar os metadados do anexo. Em servidores que usam a extensão PHP Imagick, o WordPress aciona o ImageMagick, que por sua vez chama o Ghostscript para renderizar o documento.
A cadeia funciona assim: WordPress, depois Imagick, em seguida ImageMagick e, por fim, Ghostscript. Esse último roda como um programa separado, normalmente sob a mesma conta do servidor web, e só é acionado quando algo solicita uma imagem do PDF. Um formulário que apenas salva o arquivo enviado no disco, sem mais nenhuma ação, nunca aciona o Ghostscript. Já um formulário que adiciona o arquivo à Biblioteca de Mídia pode disparar o processo quando o WordPress constrói a prévia, desde que o software necessário e as configurações estejam presentes.
É importante destacar: não se trata de uma falha no WordPress nem no plugin de formulário usado nos testes. Ambos apenas serviram de caminho para que o arquivo chegasse até o Ghostscript. O problema está no próprio Ghostscript.
Vulnerabilidade com CVSS 9,8: motivo real de preocupação?
A recomendação é clara: aplicar a correção o quanto antes. Ainda assim, vale entender que a pontuação descreve um cenário de pior caso, não uma garantia de exploração automática.
O registro da CVE atribui pontuação CVSS 3.1 de 9,8 e CVSS 4.0 de 9,3. Esses números descrevem uma aplicação voltada à internet que aceita PDFs sem exigir login ou ação do usuário, ou seja, retratam o impacto possível, não necessariamente se um site específico expõe o Ghostscript ou se um determinado PDF funcionará contra a versão instalada. A execução de código bem-sucedida roda com as permissões da conta que processa o PDF, o que não significa, automaticamente, acesso total ao sistema (root).
Sistemas modernos costumam randomizar endereços de memória e restringir partes sensíveis dos programas. Essas proteções frequentemente transformam uma corrupção de memória em uma simples falha (crash), mas não corrigem o problema de origem. Mesmo assim, no servidor de testes criado especificamente para a análise, foi possível alcançar execução de código.
Também foi testado se um único exploit funcionaria de forma universal. Foram desenvolvidos dois exploits de prova de conceito funcionais para o ambiente de laboratório, executados 10.240 vezes em dez ambientes distintos de pacotes Linux, em sistemas Intel e AMD de 64 bits: Debian, Ubuntu, Fedora, AlmaLinux, Alpine e o contêiner oficial do WordPress. Nenhum dos exploits teve sucesso fora da versão correspondente de build, enquanto ambos continuaram funcionando exatamente na versão para a qual foram desenvolvidos. Em seguida, mantendo o mesmo executável do Ghostscript, foram alteradas fontes, configurações de idioma, configuração de fontes e uma biblioteca central do sistema. O mesmo exploit continuou funcionando nos quatro cenários, embora não em todas as tentativas.
Isso reforça que a versão exata do build é determinante, mas o experimento não mediu o quão fácil seria, na prática, um atacante identificar remotamente essa versão, nem quanto tempo levaria para adaptar um exploit a um alvo real. Um atacante direcionado pode dispor de informações mais precisas, e uma plataforma de hospedagem pode expor o mesmo build em diversos sites simultaneamente. No formulário de testes, tentativas malsucedidas retornavam uma resposta de upload bem-sucedido, mesmo com o Ghostscript falhando em segundo plano — outros sites podem registrar, bloquear ou limitar uploads repetidos de forma diferente.
Os dois arquivos criados não funcionaram, sem alterações, no conjunto misto de pacotes testados. Isso é um forte indício contra tratar qualquer um dos arquivos como um exploit universal, mas não descarta a possibilidade de outro arquivo, ou conjunto de arquivos, preparado especificamente para builds mais comuns. Não houve mensuração da prevalência desses pacotes nem da identificação remota de builds, portanto não é possível apontar uma taxa de sucesso para a internet como um todo. Por isso, administradores de sites devem aplicar a correção o quanto antes, principalmente se aceitam documentos públicos ou operam diversos sites a partir de uma mesma imagem compartilhada.
![]()
![]()
A lição do caso HEIF Heist para a vulnerabilidade do Ghostscript
Estouros de buffer na heap costumam ser descartados como falhas pouco confiáveis para ataques em servidores modernos. De fato, mecanismos de randomização de memória e outras proteções dificultam a exploração, e um exploit funcional pode precisar ser ajustado a uma versão específica de software. No entanto, mais difícil não significa seguro.
Essa é justamente a conexão relevante entre esta vulnerabilidade do Ghostscript, uma descoberta anterior envolvendo a biblioteca libheif e a pesquisa HEIF Heist, conduzida pela Hacktron. Ambas as descobertas da Wordfence Argus são estouros de buffer na heap em código nativo de processamento de arquivos, acessíveis por meio de um arquivo enviado. Em ambos os casos, o exploit funcional de execução de código dependia do build específico do alvo, em vez de atuar como uma carga universal.
A pesquisa HEIF Heist demonstra por que essa limitação não deve ser confundida com proteção efetiva. A Hacktron utilizou desenvolvimento de exploits assistido por inteligência artificial para transformar um estouro de buffer na heap da libheif em execução confiável de código contra o fórum Discourse da OpenAI. A pesquisa mais ampla da Hacktron encontrou caminhos para execução de código ou exposição de dados em outros serviços e produtos reais, incluindo aplicações Next.js. Segundo a Hacktron, adaptar um exploit para cada nova empresa costumava levar de um a dois dias, mesmo quando a equipe partia de pouco conhecimento prévio sobre o ambiente-alvo. Algumas tentativas exigiram milhares de imagens enviadas, mas ainda assim a equipe conseguiu executar código ou ler dados da memória do servidor.
Os dois arquivos testados falharam em 10.240 tentativas em dez ambientes de pacotes diferentes, mas um exploit ajustado ao build específico continuou funcionando nos quatro cenários que compartilhavam exatamente o mesmo executável do Ghostscript.
Esse resultado reforça que atacantes não precisam de um único PDF capaz de funcionar em qualquer servidor, bastando concentrar esforços em um alvo conhecido ou em um grupo de servidores construídos a partir da mesma imagem-base. Diante desse cenário, a recomendação prática continua sendo a mesma: atualizar o Ghostscript para a versão 10.08.0 o quanto antes, verificar a revisão completa do pacote instalado — e não apenas a saída do comando gs –version — e reconstruir imagens de contêiner sempre que necessário, já que a falha não se limita ao ecossistema WordPress e pode afetar qualquer aplicação que processe PDFs não confiáveis, como sistemas de gestão documental, serviços de impressão, processadores de notas fiscais, gateways de e-mail e APIs de conversão de arquivos.
Com informações de wordfence.com.