CVE-2026-65640 no WordPress Core: upload PostScript pode executar código

A CVE-2026-65640 afeta o WordPress Core em servidores que usam Imagick e Ghostscript. Um usuário autenticado com capacidade de enviar mídia — normalmente Autor ou função superior — pode carregar um arquivo PostScript malicioso e fazer o processamento gerar execução remota de código. O WordPress corrigiu todas as linhas mantidas e recomenda atualização imediata.

O que aconteceu

O WordPress tenta validar tipos de arquivo antes de criar metadados e miniaturas. No cenário vulnerável, um PostScript preparado alcança a cadeia ImageMagick/Imagick e chama Ghostscript. O conteúdo então abusa do interpretador para executar operações no sistema com o usuário PHP da conta.

A falha não é puramente “do Ghostscript”: a correção do Core impede que a cadeia insegura seja acionada pelo upload permitido. Ela exige credencial com upload_files, mas sites com múltiplos autores, marketplaces, portais editoriais e senhas reutilizadas têm superfície real. O invasor pode alterar plugins, ler wp-config.php e persistir como administrador.

Uma classificação de vulnerabilidade descreve o pior cenário plausível, não confirma que cada servidor tenha sido explorado. A análise correta separa quatro perguntas: o componente existe, a versão está no intervalo afetado, as pré-condições estão presentes e houve evidência de abuso. Essa distinção evita tanto falsa tranquilidade quanto interrupções desnecessárias.

Versões e ambientes afetados e corrigidos

As quatro condições da cadeia são: Core afetado, usuário com upload_files, extensão Imagick e Ghostscript acessível. A ausência de uma delas bloqueia o exploit descrito, mas não torna aceitável manter o Core antigo, que acumula outras correções e pode ganhar nova rota.

Em pacotes de distribuição, o número upstream nem sempre muda quando o mantenedor aplica um backport. Por isso, a comparação deve considerar o release completo do pacote, o advisory do fornecedor e, quando aplicável, o estado do livepatch. Apenas comparar o primeiro número exibido pelo software pode produzir falso positivo.

Nível de risco e impacto

Alto — CVSS 3.1 8,8. A exploração requer privilégio baixo, não administrador, e termina em execução de código sem interação adicional. Em hospedagem, o efeito inicial fica no usuário da conta, mas permite roubar banco, salts, SMTP e dados pessoais, atacar outros sites da mesma conta e buscar elevação no host.

Em hospedagem, uma conta local ou um site comprometido não deve ser tratado como ator confiável. Código obtido por plugin desatualizado, credencial roubada ou upload malicioso pode satisfazer a condição “acesso local” e transformar uma falha de kernel ou painel em comprometimento de outras contas. Quando o efeito inclui root, escape, execução de PHP ou tomada de administrador, considere também bancos, chaves, tokens, e-mail e backups conectados.

Como verificar se o servidor ou site está vulnerável

Confirme versão, disponibilidade de atualização e integridade do Core. Depois verifique Imagick/Ghostscript e liste usuários capazes de publicar mídia. Não envie amostra PostScript em produção.

wp core version --extra
wp core check-update
wp core verify-checksums
php -m | grep -i '^imagick$'
gs --version 2>/dev/null
wp user list --fields=ID,user_login,roles

Versão no intervalo afetado com Imagick e Ghostscript presentes deve ser corrigida mesmo em site com um único administrador, porque credenciais podem ser roubadas. Checksums divergentes não provam exploração, mas exigem preservar e analisar arquivos. Plugins podem adicionar upload_files a funções personalizadas; revise capacidades efetivas.

Como corrigir ou mitigar

Atualize para o WordPress estável atual, preferencialmente 7.1 ou posterior; se permanecer temporariamente em ramo antigo, instale ao menos o release de segurança listado. Até concluir, remova upload de contas não essenciais e considere desabilitar o processamento Ghostscript no ambiente, após testar PDFs e geração de imagens.

wp db export backup-pre-cve-2026-65640.sql
wp core update
wp core update-db
wp core version
wp core verify-checksums

Antes da mudança, confirme backup restaurável, acesso alternativo, espaço em disco e integridade dos repositórios. Depois, valide o serviço e a aplicação em vez de considerar o comando concluído como prova suficiente. Mitigações reduzem exposição durante a janela de manutenção, mas devem ser documentadas e removidas ou reavaliadas após o patch definitivo.

Validação posterior e resposta a incidentes

Teste upload de imagens legítimas, miniaturas, editor e plugins de mídia. Procure arquivos PostScript/EPS recentes, PHP alterado, administradores desconhecidos, cron, mu-plugins e requisições de upload anormais. Se houve conta de Autor suspeita, troque senhas e salts e revise logs antes de remover artefatos.

Atualizar impede novas explorações pela falha conhecida, mas não remove persistência criada antes do patch. Se houver usuário inesperado, arquivo alterado, webshell, cron desconhecido, chave SSH nova, processo anormal ou acesso administrativo sem explicação, isole o ativo, preserve logs e acione resposta a incidentes. Faça rotação de segredos a partir de um equipamento confiável e só restaure o serviço depois de entender o alcance.

Medidas adotadas pela WebinHost

Em WordPress sob gestão contratada, a WebinHost cria backup, atualiza Core, banco e componentes, testa a aplicação e executa varredura de integridade. Imunify360 adiciona WAF, defesa proativa e detecção de malware; CloudLinux/CageFS limita a conta comprometida. Essas tecnologias reduzem impacto, mas o Core corrigido é obrigatório.

Nos serviços em que o gerenciamento da camada de servidor faz parte do contrato, o fluxo da WebinHost inclui acompanhamento dos canais de segurança dos fornecedores, inventário do componente, avaliação de exposição, aplicação controlada da correção disponível e validação posterior. Quando o kernel e a distribuição são compatíveis, o KernelCare reduz a janela de exposição ao aplicar live patches sem aguardar uma reinicialização; quando a correção exige um novo kernel ou o fornecedor não oferece live patch, a equipe planeja a atualização e o reboot conforme o risco e a janela operacional.

O Imunify360 complementa essa resposta com firewall de aplicação, detecção de malware, defesa proativa e inteligência de reputação nos planos elegíveis. Essas camadas ajudam a bloquear ou detectar tentativas, mas não substituem a correção do pacote vulnerável. CloudLinux e CageFS também aumentam o isolamento entre contas, sem transformar uma versão desatualizada em versão segura.

Referências oficiais e técnicas

• WordPress.org — WordPress 7.0.4 Security Release
• WordPress — advisory GHSA-8vr3-7mxf-gx8w
• CVE.org — CVE-2026-65640

Nota técnica: distribuições Linux e painéis frequentemente aplicam backports. O número exibido por um pacote pode ser diferente da versão upstream e ainda conter a correção. Compare sempre o pacote com o advisory da distribuição ou do painel. Não execute prova de conceito em produção; os comandos deste boletim são de inventário e verificação.