WordPress 7.0.4 corrige uma falha de execução remota de código ligada ao upload de arquivos maliciosos em servidores que usam Imagick e Ghostscript. O problema exige uma conta com permissão de upload, mas o impacto pode chegar ao controle do site. Se a atualização ainda não apareceu como concluída, trate a checagem como prioridade.
Resumo rápido
- A falha é a CVE-2026-65640, classificada como alta, com pontuação CVSS 8,8.
- O cenário documentado exige Imagick e Ghostscript no servidor e um usuário com a capacidade
upload_files. - WordPress 7.0.0 a 7.0.3 estão entre as versões afetadas; 7.0.4 contém a correção.
- Branches antigas receberam backports próprios. Não instale 7.0.4 por cima de uma branch antiga sem planejar a atualização principal.
- Faça backup, atualize, confirme a versão e revise contas que podem enviar mídia.
Fonte e revisão: conteúdo revisado em 14 de agosto de 2026 com o comunicado, a documentação de versão e o advisory oficial do projeto WordPress. Detalhes de exploração podem mudar conforme novas análises são publicadas.
O que o WordPress 7.0.4 corrige?
O comunicado oficial do WordPress 7.0.4, publicado em 12 de agosto, descreve uma falha de execução remota de código autenticada. Ela pode ser acionada por upload de arquivo malicioso em instalações que processam imagens com Imagick e Ghostscript.
Execução remota de código, ou RCE, significa que um invasor pode tentar fazer o servidor executar instruções que não deveriam fazer parte do site. Nesse caso, a vulnerabilidade não é apresentada como acesso anônimo: o advisory exige uma conta com nível Autor ou superior, ou outra função que possua a capacidade upload_files.
Isso reduz o conjunto de atacantes, mas não torna o risco irrelevante. Sites com muitos autores, equipes terceirizadas, contas antigas, senhas reutilizadas ou credenciais comprometidas têm uma superfície maior. Uma conta legítima roubada pode fornecer exatamente a permissão necessária.
Cuidado: não conclua que o site está seguro apenas porque você não cria imagens manualmente. O risco depende da pilha de processamento do servidor e das permissões de upload das contas, não do seu hábito editorial.
Quem está exposto à falha de upload?
O advisory da CVE-2026-65640 lista dois pré-requisitos técnicos: Imagick e Ghostscript precisam estar em uso no servidor, e o usuário malicioso precisa ter permissão para enviar arquivos. A fraqueza está relacionada ao tratamento de arquivos PostScript incorporados pelo Ghostscript.
Na prática, o primeiro diagnóstico é uma matriz, não um simples “uso WordPress”. Quanto mais condições se confirmam, maior a urgência operacional. Ainda assim, a recomendação oficial é atualizar imediatamente porque a correção também está disponível para branches antigas afetadas.
| Condição | O que observar | Decisão |
|---|---|---|
| WordPress 7.0.0 a 7.0.3 | Versão exibida em Painel → Atualizações | Atualizar para 7.0.4 |
| Branch antiga afetada | Ex.: 6.9.0 a 6.9.6 ou 6.8.0 a 6.8.7 | Instalar o backport da própria branch e planejar upgrade |
| Imagick e Ghostscript | Confirmação no host ou relatório de diagnóstico | Tratar o cenário documentado como aplicável |
| Contas com upload | Autores, editores, administradores e funções personalizadas | Revisar acessos, sessões e necessidade de permissão |
A documentação da versão 7.0.4 mostra que a correção também foi distribuída para versões desde a branch 4.7. As versões corrigidas incluem 6.9.7, 6.8.8, 6.7.7 e equivalentes nas linhas mantidas. WordPress 4.6 e anteriores já não recebem atualização de segurança.
Como saber se seu servidor usa Imagick e Ghostscript?
Não instale plugin desconhecido só para responder essa pergunta. Primeiro, abra Ferramentas → Saúde do site → Informação e procure a seção de mídia. O relatório costuma indicar se o módulo Imagick está disponível. A presença do Ghostscript pode não aparecer de forma clara, então o caminho mais seguro é pedir confirmação ao provedor de hospedagem.
Se você administra o servidor, valide os pacotes e a configuração no ambiente correto, sem publicar comandos ou versões sensíveis em tickets abertos. Em hospedagem gerenciada, envie uma pergunta objetiva: “este site processa uploads com Imagick e Ghostscript, e o WordPress já recebeu o patch correspondente à CVE-2026-65640?”.
Perguntas para o provedor
- Qual versão do WordPress está ativa neste site agora?
- Imagick e Ghostscript processam uploads de mídia?
- O patch da CVE-2026-65640 já foi aplicado ou backportado?
- Houve upload incomum ou execução suspeita desde 12 de agosto?
- Existe backup íntegro anterior à atualização e teste de restauração?
O fato de o servidor usar apenas GD para imagens pode afastar o cenário específico descrito no advisory, mas não justifica manter o Core desatualizado. Segurança não é uma soma de desculpas: cada release corrige um conjunto conhecido de falhas, e versões antigas acumulam exposição.
Como atualizar sem derrubar o site?
Para um update de segurança do Core, a prioridade é velocidade com capacidade de voltar atrás. A documentação oficial sobre atualização do WordPress orienta manter backup e usar o fluxo do painel ou o método manual conforme o ambiente.
- Registre a versão atual: salve a tela do painel, o horário e o ambiente que será atualizado.
- Faça backup verificável: inclua banco de dados e arquivos. Um arquivo criado sem teste de leitura não é prova de recuperação.
- Pause mudanças simultâneas: não atualize dez plugins, tema e PHP no mesmo lote se você precisa identificar uma regressão.
- Atualize o Core: em Painel → Atualizações, instale a versão corrigida indicada para sua branch.
- Limpe somente o cache necessário: evite purges globais sem diagnóstico, mas confirme que o painel e o front-end carregam a versão nova.
- Teste o caminho de receita: abra páginas de entrada, formulário, checkout, anúncios, analytics e sitemap.
- Revise logs e contas: procure uploads anormais, novos usuários, alteração de arquivos e sessões que não reconhece.
Regra prática: em um blog monetizado, “site abriu” não encerra o QA. Valide URL pública, formulário, pixels, anúncios, robots, canonical e sitemap antes de considerar a atualização concluída.
Se você ainda está organizando manutenção, o nosso setup essencial de WordPress para blog ajuda a separar base técnica de melhorias opcionais. Para reforçar o acesso administrativo, veja também como proteger a URL de login do WordPress, sem confundir ocultação de URL com correção do Core.
O auto-update elimina a necessidade de conferir?
Não. Atualizações automáticas reduzem o tempo de exposição, mas podem atrasar por fila do provedor, política interna, bloqueio de escrita ou configuração da hospedagem. Abra o painel e confirme a versão instalada. Se o host informar que aplicou backport, peça o número exato da versão e o registro da mudança.
Também vale separar “update baixado” de “site validado”. Um processo pode concluir a troca de arquivos e ainda deixar cache antigo, tarefa de banco pendente ou incompatibilidade em um fluxo específico. A validação pós-update precisa ser curta o bastante para acontecer sempre.
O que revisar nas contas com permissão de upload?
O advisory exige a capacidade upload_files. No WordPress padrão, Autores, Editores e Administradores costumam ter essa permissão; funções personalizadas podem ampliar ou reduzir o acesso. Revise usuários ativos e remova contas antigas que não precisam mais publicar.
Troque senhas de contas suspeitas, encerre sessões, confirme e-mails administrativos e habilite autenticação em dois fatores quando o seu stack permitir. Se freelancers publicam mídia, prefira acessos individuais e temporários. Uma conta compartilhada impede saber quem fez o quê.
Depois, compare a biblioteca de mídia e os logs com o padrão normal do site. Arquivos com nomes incomuns, extensões inesperadas, uploads fora do horário ou usuários criados sem solicitação justificam investigação. Não apague evidências antes de preservar logs e backup.
Como a falha pode afetar tráfego e receita?
Uma invasão não precisa derrubar o site para causar prejuízo. Código injetado pode alterar links, redirecionar visitantes, criar páginas de spam, capturar credenciais ou bloquear rastreamento. Para SEO, isso pode gerar URLs desconhecidas, canonical alterado, robots indevido ou avisos de segurança.
Em um site monetizado, o impacto também aparece em anúncios, afiliados e reputação. Uma página que redireciona parte do público pode reduzir receita sem produzir um erro visível para todos. Por isso, a conexão com tráfego é operacional: atualizar o Core protege disponibilidade, indexação, medição e conversão.
Uploads legítimos também merecem atenção. Depois do update, teste JPEG, PNG, WebP ou o formato usado pela equipe e confira as miniaturas. O guia de SEO para imagens e GIFs ajuda a manter peso, formato e indexação sob controle após mudanças no processamento de mídia.
WordPress 7.0.2 ainda protege o site?
O 7.0.2 corrigiu outras falhas importantes em julho, mas não inclui a correção lançada no 7.0.4. Segurança de software é cumulativa: instalar um patch anterior não substitui o próximo. Nosso artigo sobre a falha crítica corrigida no WordPress 7.0.2 serve como histórico, não como recomendação de versão atual.
Se o painel ainda mostra 7.0.2 ou 7.0.3, atualize para 7.0.4. Se mostra uma branch antiga, consulte a tabela oficial de backports e instale a versão corrigida correspondente. Depois, planeje sair de uma linha antiga porque apenas a versão mais recente recebe suporte ativo completo.
Perguntas frequentes
A falha pode ser explorada sem login?
O cenário oficial exige um usuário autenticado com permissão de upload. Isso não elimina o risco de credenciais roubadas ou contas antigas. Revise usuários e aplique o patch mesmo que o cadastro público esteja fechado.
Preciso desinstalar o Imagick?
Não como primeira resposta. O WordPress 7.0.4 corrige a vulnerabilidade, e branches antigas receberam backports. Desativar um componente sem avaliar o impacto pode quebrar miniaturas e formatos; atualize e confirme a configuração com o host.
Qual versão devo instalar?
Na linha 7.0, instale 7.0.4. Em branches antigas afetadas, use o backport oficial da própria linha, como 6.9.7 ou 6.8.8, e planeje a atualização principal. Não permaneça em 4.6 ou anterior, porque essas versões não recebem esse patch.
Como confirmo que a atualização funcionou?
Confira o número da versão em Painel → Atualizações, teste o front-end e o admin, envie uma imagem legítima, valide formulários, analytics, anúncios e sitemap. Registre horário, versão e resultado do QA.
Conclusão
WordPress 7.0.4 é uma atualização de segurança material, não uma troca cosmética de versão. O patch fecha uma RCE que combina upload autorizado, Imagick e Ghostscript. Sites com equipes editoriais e muitas contas precisam olhar tanto a versão quanto as permissões.
Faça backup, instale a correção adequada à sua branch e valide os caminhos que sustentam tráfego e receita. Se encontrar upload ou usuário que não reconhece, preserve evidências e acione a hospedagem ou um profissional de resposta a incidentes.
Seu host aplicou o 7.0.4 automaticamente ou você precisou atualizar pelo painel? Compartilhe a experiência nos comentários.
