WordPress 7.0.4: Falha Crítica no Imagick Ameaça Sites

Neste artigo do Blog Dolutech, vamos analisar em profundidade o lançamento da versão 7.0.4 do WordPress, publicada em 12 de agosto de 2026, e o que ela representa dentro de um dos ciclos de patches mais intensos já registrados no núcleo do CMS mais usado do planeta. Em menos de noventa dias, o WordPress passou por cinco lançamentos consecutivos (7.0, 7.0.1, 7.0.2, 7.0.3 e 7.0.4), sendo que três deles foram classificados como releases de segurança crítica. A Dolutech acompanhou toda essa sequência de perto, e o que encontramos não é um caso isolado de bug corrigido às pressas, mas um sintoma de uma mudança estrutural na forma como vulnerabilidades estão sendo descobertas, weaponizadas e exploradas em escala global, com inteligência artificial atuando dos dois lados do tabuleiro.

A versão 7.0.4 corrige uma falha de execução remota de código (RCE) que exige autenticação prévia como Autor, mas que se torna extremamente perigosa em qualquer site que combine a extensão PHP Imagick com o interpretador Ghostscript, uma combinação de software presente por padrão em uma fatia enorme das instalações WordPress hospedadas em servidores Linux. Abaixo, detalhamos a cronologia completa, o funcionamento técnico da falha, o mapeamento MITRE ATT&CK, os indicadores de comprometimento conhecidos, os comandos de mitigação e o panorama regulatório que empresas na Europa e no Brasil precisam observar.

O mês em que o WordPress não parou de corrigir falhas

Para entender a gravidade do momento, é preciso olhar para a linha do tempo completa. Nós reunimos os cinco lançamentos mais recentes do núcleo do WordPress na tabela abaixo, com a data oficial de publicação e a natureza de cada correção.

Versão	Data de lançamento	Tipo de release	Principal correção
7.0	20 de maio de 2026	Major	Nova versão principal do núcleo, encerramento do suporte ao PHP 7.2 e 7.3
7.0.1	9 de julho de 2026	Manutenção	31 correções de bugs no núcleo e no editor de blocos
7.0.2	17 de julho de 2026	Segurança crítica	Cadeia WP2Shell: CVE-2026-60137 e CVE-2026-63030, RCE pré-autenticado
7.0.3	6 de agosto de 2026	Segurança crítica	12 falhas corrigidas, destaque para o CVE-2026-64638, apelidado de XSS2Shell
7.0.4	12 de agosto de 2026	Segurança crítica	RCE autenticado (Autor+) via Imagick e Ghostscript em upload de arquivo

Repare no intervalo entre cada release: pouco mais de duas semanas entre a 7.0.2 e a 7.0.3, e apenas seis dias entre a 7.0.3 e a 7.0.4 lançada hoje. Esse ritmo não é comum para um projeto que, historicamente, passava meses inteiros sem precisar de um release de segurança fora do calendário. A Dolutech entende que isso reflete diretamente o tema que discutimos a seguir: pesquisadores de segurança, tanto ofensivos quanto defensivos, estão usando modelos de linguagem para acelerar a descoberta de vulnerabilidades em uma velocidade que o processo tradicional de revisão de código simplesmente não acompanhava até agora.

WordPress 7.0.4: a falha crítica no Imagick e no Ghostscript

O boletim oficial da WordPress.org, publicado nesta quarta-feira, descreve a correção da versão 7.0.4 de forma direta: uma falha de execução remota de código autenticada, explorável por qualquer usuário com papel de Autor ou superior, através do upload de um arquivo malicioso em sites que utilizam Imagick em conjunto com Ghostscript para o processamento de imagens. A equipe de pesquisa pwn.ai foi responsável pelo relato responsável da falha. O arquivo revisado no núcleo foi o wp-includes/class-wp-image-editor-imagick.php, o que confirma que o problema está na forma como o WordPress delega o processamento de determinados formatos de imagem para bibliotecas externas.

Diferente do WP2Shell, que não exigia nenhuma autenticação, essa falha do 7.0.4 depende de uma conta com permissão de upload de mídia, ou seja, no mínimo o papel de Autor. Isso reduz a superfície de ataque direta, mas não elimina o risco. Sites com cadastro aberto de usuários, plugins de fórum, marketplaces com upload de portfólio por vendedores, ou WordPress Multisite com registro de usuários habilitado, colocam exatamente esse tipo de conta com privilégio mínimo nas mãos de qualquer visitante mal-intencionado. A partir daí, um único upload de imagem cuidadosamente construído pode ser suficiente.

Como funciona o RCE via Imagick e Ghostscript

O padrão técnico por trás dessa classe de vulnerabilidade já é conhecido pela comunidade de segurança havia anos, desde os primeiros casos de ImageTragick em 2016, mas continua ressurgindo porque o problema de fundo nunca foi completamente resolvido: quando o ImageMagick, ou sua extensão PHP Imagick, recebe um arquivo que não consegue processar diretamente, ele delega esse processamento a ferramentas auxiliares, sendo o Ghostscript a mais comum para arquivos PostScript e PDF. O Ghostscript, por sua vez, possui um sandbox de segurança chamado -dSAFER, criado justamente para impedir que um arquivo malicioso escreva no sistema de arquivos ou execute comandos.

O problema, documentado em pesquisas recentes da própria pwn.ai sobre o ecossistema ImageMagick, é que esse sandbox pode ser contornado através da Magick Scripting Language (MSL), um formato de script interno do ImageMagick que consegue escapar das restrições impostas ao Ghostscript. Um arquivo de imagem disfarçado, com extensão .jpg ou .png, mas com um cabeçalho ou conteúdo interno reconhecido como PostScript, pode instruir o Ghostscript a escrever um arquivo arbitrário no diretório temporário do servidor. Combinado com técnicas de MSL, esse arquivo escrito pode se transformar em um webshell funcional, entregando execução de código ao atacante com o mesmo nível de privilégio do processo PHP-FPM ou Apache que está rodando o WordPress.

O ponto crítico levantado pela pwn.ai é que o WordPress, por padrão, não define nenhuma política de segurança própria para o ImageMagick. Ele simplesmente confia no arquivo policy.xml que já vier configurado no servidor. Em distribuições populares como o Ubuntu 22.04 LTS, que ainda concentra uma fatia enorme dos servidores WordPress do mundo, a combinação de versões de ImageMagick e Ghostscript instaladas por padrão é, segundo a própria pesquisa, uma das configurações mais expostas que existem para esse tipo de ataque.

Quem está exposto

Até o momento da publicação deste artigo, a WordPress.org ainda não havia atribuído um identificador CVE público para essa falha específica corrigida na 7.0.4, o que é comum em releases publicados poucas horas antes, já que a atribuição de CVE costuma levar alguns dias. O que já sabemos, porque consta oficialmente no changelog da versão, é que o problema afeta absolutamente todas as branches do WordPress ainda sob suporte, do 4.7 ao 6.9, e que a WordPress.org já disponibilizou backports para todas elas, de 4.7.35 até 6.9.7. Isso, por si só, é um indicativo da gravidade: quando um bug de segurança é corrigido simultaneamente em vinte versões diferentes do núcleo, ele existe desde muito antes de ter sido descoberto.

WP2Shell e XSS2Shell: quando a IA acelera a corrida entre ataque e defesa

Se a falha da 7.0.4 já preocupa por si só, o contexto em que ela surge é ainda mais relevante para quem trabalha com segurança. As duas correções anteriores, na 7.0.2 e na 7.0.3, têm uma origem em comum que a Dolutech considera um marco: ambas nasceram de pesquisas de vulnerabilidade assistidas por modelos de linguagem de grande escala.

A cadeia batizada de WP2Shell, corrigida na versão 7.0.2, combina duas falhas que isoladamente não geram grande impacto, mas que encadeadas resultam em execução remota de código sem qualquer autenticação. A primeira, catalogada como CVE-2026-63030, é uma condição de interpretação inconsistente no endpoint de processamento em lote da REST API do WordPress, acessível em /wp-json/batch/v1 ou /?rest_route=/batch/v1. A segunda, CVE-2026-60137, é uma injeção SQL clássica no parâmetro author__not_in da classe WP_Query. Sozinha, a falha de rota confusa não expõe nada crítico. Combinada com a injeção SQL, um atacante anônimo consegue, com uma única requisição POST, criar uma conta de administrador no site alvo.

O que chamou a atenção da comunidade de segurança não foi apenas a gravidade técnica, mas a origem da descoberta. De acordo com a Searchlight Cyber, empresa responsável pelo achado, a cadeia completa foi identificada por um modelo de linguagem de grande escala em cerca de dez horas de trabalho autônomo, a um custo estimado de poucas dezenas de dólares em tokens de API. Esse mesmo tipo de vulnerabilidade, décadas atrás presente em código legado do WordPress, exigiria semanas de auditoria manual especializada para ser encontrada. A cadeia foi adicionada ao catálogo de Vulnerabilidades Conhecidas e Exploradas (KEV) da CISA já em 21 de julho de 2026, quatro dias após a divulgação pública, e provas de conceito totalmente automatizadas circularam livremente em fóruns de segurança horas depois disso. Equipes de resposta a incidentes, incluindo a Bitdefender MDR, documentaram ataques reais criando contas administrativas com o prefixo w2s_, uma assinatura que se tornou um indicador de comprometimento amplamente reconhecido.

Três semanas depois, a versão 7.0.3 trouxe a correção para outra cadeia igualmente séria, apelidada de XSS2Shell pela própria pwn.ai, responsável pela descoberta. Trata-se de uma vulnerabilidade de cross-site scripting refletido, pré-autenticada, na tela de login do WordPress, catalogada como CVE-2026-64638, com potencial de escalar para execução remota de código completa quando um administrador autenticado interage com um link malicioso preparado pelo atacante. A pesquisa se baseia em uma técnica anterior de Same Origin Method Execution (SOME), que já havia rendido um bypass de Content Security Policy afetando a mesma fatia expressiva de sites WordPress do mundo. Segundo a própria pwn.ai, a falha estava presente desde as primeiras versões do WordPress e passou despercebida por auditorias de segurança durante anos, até ser finalmente identificada agora.

A Dolutech vê nesse padrão uma tendência que vai muito além do WordPress: ferramentas de IA generativa estão reduzindo drasticamente o tempo e o custo necessário para encontrar vulnerabilidades de dia zero em softwares amplamente utilizados, tanto nas mãos de pesquisadores éticos quanto, potencialmente, de agentes maliciosos. Isso significa que o intervalo entre a divulgação de uma falha e a sua exploração massiva em produção está encolhendo, e que empresas que dependem de ciclos de patch manuais e esporádicos correm um risco crescente de ficarem para trás.

Mapeamento MITRE ATT&CK

Para facilitar a análise por equipes de SOC e de resposta a incidentes, mapeamos as técnicas do MITRE ATT&CK Enterprise associadas às três falhas discutidas neste artigo.

Técnica	ID	Tática	Aplicação no caso WordPress
Exploit Public-Facing Application	T1190	Initial Access	Exploração direta do endpoint REST de batch (WP2Shell) e da tela pública de login (XSS2Shell) sem necessidade de credenciais
Exploitation for Client Execution	T1203	Execution	Execução de JavaScript malicioso no contexto do administrador autenticado através da cadeia XSS2Shell
Command and Scripting Interpreter	T1059	Execution	Interpretação de comandos PostScript maliciosos pelo Ghostscript durante o processamento de imagem via Imagick
Exploitation for Privilege Escalation	T1068	Privilege Escalation	Escalonamento de um usuário com papel de Autor para controle efetivo do servidor via upload de arquivo malicioso na falha corrigida em 7.0.4
Create Account: Local Account	T1136.001	Persistence	Criação de contas administrativas com prefixo w2s_, documentadas em ataques reais explorando a cadeia WP2Shell
Web Shell	T1505.003	Persistence	Implantação de webshells persistentes após comprometimento inicial via escrita arbitrária de arquivo
Exploitation for Defense Evasion	T1211	Defense Evasion	Contorno do sandbox -dSAFER do Ghostscript por meio de técnicas MSL do ImageMagick
Data Manipulation	T1565	Impact	Manipulação de dados do banco via injeção SQL no parâmetro author__not_in

Indicadores de comprometimento (IoC)

É importante reforçar que nem todas as falhas discutidas neste artigo já possuem indicadores públicos consolidados. A Dolutech optou por listar apenas o que está de fato confirmado por fornecedores de segurança, sinalizando claramente onde ainda não há confirmação pública.

Indicador	Tipo	Contexto	Status de confirmação
Requisições POST para /?rest_route=/batch/v1 ou /wp-json/batch/v1 com múltiplos objetos aninhados na mesma chamada	Padrão de rede	Exploração da cadeia WP2Shell (CVE-2026-63030 e CVE-2026-60137)	Confirmado por múltiplos fornecedores, incluindo Wiz e Bitdefender
Contas de administrador criadas com o prefixo w2s_	Indicador de host	Persistência após exploração bem-sucedida do WP2Shell	Confirmado pela Bitdefender MDR em investigação de incidente real
Arquivos de imagem (.jpg, .png, .eps) com cabeçalho ou conteúdo interno reconhecido como PostScript, ou comandos MSL embutidos	Artefato de arquivo	Vetor de exploração de Imagick e Ghostscript, base da falha corrigida na 7.0.4	Padrão de exploração documentado em pesquisa correlata; não há confirmação pública de campanha específica contra a 7.0.4 até a publicação deste artigo
Requisições repetidas à tela de login com parâmetros de redirecionamento incomuns ou origens cruzadas suspeitas	Padrão de rede	Possível tentativa de exploração da cadeia XSS2Shell (CVE-2026-64638)	Sem indicadores públicos oficiais divulgados até o momento
Identificador CVE específico da falha de Imagick corrigida na versão 7.0.4	Identificador	Falha de RCE autenticado relatada pela pwn.ai	Ainda não publicado oficialmente pela WordPress.org, MITRE ou NVD no momento desta publicação

Mitigação técnica: como proteger seu WordPress agora

A recomendação central, para qualquer uma das falhas discutidas, é a mesma: atualizar imediatamente. Mas a Dolutech sabe que, na prática, empresas que administram dezenas ou centenas de instalações precisam de mais do que um lembrete, precisam de comandos prontos para auditoria e mitigação em escala.

Atualização do núcleo via WP-CLI, com verificação de integridade dos arquivos:

wp core update --version=7.0.4 --force
wp core verify-checksums
wp plugin list --update=available

Hardening da política do ImageMagick para desabilitar os coders que permitem delegação ao Ghostscript, reduzindo drasticamente a superfície de ataque mesmo antes da atualização do núcleo:

sudo tee -a /etc/ImageMagick-6/policy.xml <<'EOF'
<policy domain="coder" rights="none" pattern="PS" />
<policy domain="coder" rights="none" pattern="EPS" />
<policy domain="coder" rights="none" pattern="PDF" />
<policy domain="coder" rights="none" pattern="XPS" />
EOF

identify -list policy | grep -i coder

Observação: o caminho do arquivo policy.xml varia conforme a distribuição e a versão instalada, podendo estar em /etc/ImageMagick-6/ ou /etc/ImageMagick-7/. Vale confirmar o caminho correto com find / -name policy.xml 2>/dev/null antes de aplicar o ajuste.

Bloqueio e limitação de requisições ao endpoint de batch da REST API, útil como mitigação temporária contra tentativas de exploração do WP2Shell em sites que ainda não puderam ser atualizados:

limit_req_zone $binary_remote_addr zone=wp_batch:10m rate=2r/s;

location ~* ^/wp-json/batch/v1 {
    limit_req zone=wp_batch burst=5 nodelay;
    if ($request_method !~ ^(GET|POST)$) {
        return 405;
    }
}

Script simples para auditar em lote a versão do núcleo em várias instalações WordPress administradas via WP-CLI, essencial para quem cuida de uma frota de sites:

#!/bin/bash
while IFS= read -r site_path; do
    version=$(wp core version --path="$site_path" --allow-root 2>/dev/null)
    echo "${site_path}: versão detectada ${version}"
done < sites.txt

Script em Python para checar remotamente a versão exposta via REST API de múltiplos domínios, útil para agências e times de segurança que monitoram sites de terceiros sem acesso SSH direto:

import requests

sites = [
    "https://exemplo1.com.br",
    "https://exemplo2.pt",
]

for site in sites:
    try:
        resposta = requests.get(f"{site}/wp-json", timeout=8)
        versao = resposta.json().get("wp_version", "não exposta pela API")
        print(f"{site}: versão detectada {versao}")
    except Exception as erro:
        print(f"{site}: erro ao verificar ({erro})")

Além dos comandos, algumas práticas de configuração merecem atenção redobrada neste momento: revisar quais papéis de usuário têm permissão de upload de mídia, desabilitar o registro público de usuários em instalações Multisite que não precisem dessa funcionalidade, e considerar a migração do processamento de imagens para a extensão GD em ambientes que não dependam de recursos avançados do Imagick, eliminando por completo essa classe de risco.

A solução DolutechAI com conector WordPress

Diante desse cenário de patches consecutivos e prazos cada vez mais curtos entre descoberta e exploração em massa, manter uma frota de sites WordPress protegida manualmente deixou de ser viável para a maioria das equipes. Foi exatamente para resolver esse problema que a Dolutech desenvolveu o conector WordPress da DolutechAI, uma camada de monitoramento contínuo que conecta diretamente ao painel administrativo e à REST API de cada instalação sob gestão.

Na prática, o conector realiza verificações periódicas da versão do núcleo, de plugins e de temas instalados, cruzando essas informações automaticamente com bases de vulnerabilidades públicas, incluindo o catálogo KEV da CISA e os boletins oficiais da WordPress.org. Quando uma falha crítica como as que discutimos neste artigo é publicada, a DolutechAI já cruza o CVSS, o status de exploração ativa e a exposição real de cada site monitorado, priorizando os alertas por risco real e não apenas por severidade genérica. Nós também geramos automaticamente os comandos de mitigação recomendados para cada caso, no mesmo formato que usamos ao longo deste artigo, prontos para revisão e execução pelo time técnico responsável.

Para quem administra dezenas de sites entre clientes, franquias ou múltiplas marcas, esse tipo de visibilidade centralizada é o que separa uma resposta a incidente feita em minutos de uma descoberta tardia, semanas depois, quando o dano já está feito. A Dolutech recomenda a qualquer administrador que ainda dependa de checagens manuais avaliar essa camada adicional de automação, especialmente diante do ritmo de releases de segurança que o WordPress vem sustentando neste segundo semestre de 2026.

https://dolutech.ai/pt/wordpress-security-plugin

Panorama regulatório: Europa e Brasil

Falhas críticas em um CMS que sustenta uma fatia tão relevante da internet global não são apenas um problema técnico, são também uma questão de conformidade regulatória, tanto na União Europeia quanto no Brasil.

Na Europa, a Diretiva NIS2 exige que entidades essenciais e importantes, categoria que inclui provedores de hospedagem, plataformas digitais e uma ampla gama de operadores de infraestrutura crítica, notifiquem incidentes significativos às autoridades competentes em prazos que começam em 24 horas para o alerta inicial e se estendem até 72 horas para um relatório mais detalhado. Uma exploração bem-sucedida de qualquer uma das falhas discutidas aqui, especialmente a cadeia WP2Shell, que já resultou em criação de contas administrativas não autorizadas e implantação de webshells, se enquadra facilmente nessa definição de incidente significativo. Instituições financeiras e seus prestadores de serviços de TI também precisam observar o Regulamento DORA, que trata especificamente da resiliência operacional digital e da gestão de risco de terceiros, categoria na qual se enquadra qualquer CMS utilizado por uma instituição regulada ou por seus fornecedores. O Regulamento Geral de Proteção de Dados (GDPR) permanece aplicável sempre que dados pessoais estiverem em risco, com a obrigação de notificação à autoridade supervisora em até 72 horas, conforme o artigo 33.

Em Portugal, o Centro Nacional de Cibersegurança (CNCS) e o CERT.PT desempenham papel central na coordenação nacional de resposta a esse tipo de incidente, emitindo alertas e recomendações específicas para administradores de sites baseados em WordPress sempre que vulnerabilidades dessa magnitude são divulgadas. Já no Brasil, a Lei Geral de Proteção de Dados (LGPD) impõe à Autoridade Nacional de Proteção de Dados (ANPD) a obrigação de comunicação de incidentes de segurança que possam acarretar risco relevante aos titulares de dados, processo formalizado pela Resolução ANPD nº 15/2024, que detalha prazos e conteúdo mínimo dessa comunicação. Empresas brasileiras que operam sites WordPress voltados a e-commerce, captação de leads ou qualquer tratamento de dados pessoais precisam considerar essas falhas dentro do próprio programa de gestão de incidentes exigido pela LGPD.

Considerações finais da Dolutech

A sequência de lançamentos do WordPress entre maio e agosto de 2026 marca uma mudança de patamar na velocidade com que vulnerabilidades críticas estão sendo descobertas e exploradas. A versão 7.0.4, publicada nesta quarta-feira, é mais um capítulo dessa história, e certamente não será o último. Para a Dolutech, a lição prática é clara: ciclos de atualização manual e esporádica não são mais suficientes para acompanhar o ritmo imposto por ferramentas de descoberta de vulnerabilidades assistidas por IA. Manter o núcleo, os plugins e os temas atualizados continua sendo a defesa mais eficaz e mais barata disponível, mas ela precisa ser sustentada por monitoramento contínuo, priorização baseada em risco real e processos de resposta capazes de agir em horas, não em semanas. Continuaremos acompanhando os próximos desdobramentos dessa série de correções e traremos atualizações assim que novos detalhes, incluindo o identificador CVE oficial da falha corrigida na 7.0.4, forem publicados.