Verificar checksums do WordPress: ficheiros alterados

Se suspeita de que o site foi comprometido, a verificação de checksums é uma boa primeira verificação, mas não deve atrasar a contenção nem a preservação de provas. Um único comando diz-lhe se os ficheiros do núcleo (core) são idênticos, byte a byte, à versão oficial. Os ficheiros abrangidos pela lista oficial de checksums têm de corresponder à sua versão e ao seu idioma exatos. Ficheiros específicos do site, como o wp-config.php, ficam fora dessa comparação. Qualquer diferença é uma alteração local que conhece ou algo a investigar hoje mesmo.

Porque é que os ficheiros do núcleo do WordPress mudam após um ataque

Os ficheiros do núcleo são um bom esconderijo, porque ninguém os lê. Quem gere um site olha para as definições do tema e dos plugins. Quase ninguém abre wp-includes/load.php nem conta os ficheiros em wp-admin/includes. Um atacante pode esconder código num ficheiro do núcleo que é carregado com regularidade ou acrescentar um ficheiro de aspeto plausível para aceder mais tarde. Um ficheiro acrescentado não é executado só por estar numa pasta do núcleo.

Os checksums transformam o «parece estar tudo bem» numa comparação demonstrável. O WordPress.org publica um hash MD5 para cada ficheiro do núcleo de cada versão. Compara os seus ficheiros com essa lista.

Não perca a causa de vista, no entanto. O relatório State of WordPress Security in 2026, da Patchstack, é de um fornecedor. Conta apenas 6 vulnerabilidades no núcleo do WordPress em 2025, todas de baixa prioridade. Esse número não lhe diz como o atacante entrou no seu site. Ficheiros do núcleo alterados podem resultar de uma intrusão através de um plugin, de um tema ou de credenciais roubadas. Substituir o núcleo repara esses ficheiros, mas continua a ser preciso identificar e fechar o ponto de entrada.

Como verificar os checksums do WordPress com WP-CLI

Ligue-se por SSH e execute o comando a partir do diretório raiz do WordPress:

cd /var/www/example.com
wp core verify-checksums

Se estiver noutro diretório, acrescente --path=/var/www/example.com. Execute o comando com o utilizador proprietário dos ficheiros do site, não como root. O WP-CLI recusa-se a correr como root, a menos que acrescente --allow-root, e essa predefinição faz sentido: como root, qualquer código malicioso carregado pelo WordPress também correria como root.

Por predefinição, o WP-CLI lê a versão em wp-includes/version.php. Num site comprometido, esse ficheiro também pode estar alterado. Se sabe que versão instalou, indique-a. Em instalações que não estejam em inglês, defina também o locale:

wp core verify-checksums --version=6.8.3 --locale=de_DE

Use o seu próprio número de versão. Num site limpo, vê uma única linha:

Success: WordPress installation verifies against checksums.

Num site com problemas, vê avisos como estes:

Warning: File doesn't verify against checksum: wp-includes/functions.php
Warning: File should not exist: wp-includes/class-wp-cache-handler.php
Error: WordPress installation doesn't verify against checksums.

Interpretar os resultados: ficheiros alterados e ficheiros extra

Os dois tipos de aviso significam coisas diferentes e exigem tratamento diferente.

Considere grave um ficheiro alterado, a não ser que saiba de uma correção local legítima. Essas correções são raras e quem as fez deveria tê-las documentado.

Um ficheiro extra é menos claro. Algumas atualizações deixam para trás ficheiros de versões antigas, por isso um ficheiro extra não é prova de malware. Um ficheiro PHP com nome aleatório em wp-includes é suspeito até o ler. O mesmo vale para um ficheiro cujo nome apenas soa a componente do núcleo.

Os ficheiros extra podem ser comunicados como avisos sem que o comando falhe. Pode ver linhas File should not exist seguidas de Success. Leia todos os avisos em vez de confiar na última linha.

Por predefinição, a verificação de ficheiros extra abrange wp-admin e wp-includes. Algumas versões do WP-CLI também conseguem verificar o diretório raiz. Execute wp help core verify-checksums para ver se a sua versão oferece --include-root.

Sem WP-CLI? Use a API de checksums do WordPress.org

Alguns alojamentos oferecem SSH mas não têm WP-CLI. Nesse caso, consulte diretamente a API de checksums e deixe o md5sum comparar os ficheiros. Precisa de curl e jq:

cd /var/www/example.com
VER=6.8.3        # a sua versão exata do WordPress
LOC=en_US        # ou pt_PT, de_DE, fr_FR, ...
(
  set -e
  WORK=$(mktemp -d)
  trap 'rm -rf -- "$WORK"' EXIT
  curl -fsS "https://api.wordpress.org/core/checksums/1.0/?version=$VER&locale=$LOC" \
    -o "$WORK/response.json"
  jq -er '.checksums | select(type == "object" and length > 0) | to_entries[] | select(.key | startswith("wp-content/") | not) | "\(.value)  \(.key)"' \
    "$WORK/response.json" > "$WORK/core.md5"
  test -s "$WORK/core.md5"
  md5sum -c --quiet "$WORK/core.md5"
)

O filtro select ignora os temas e plugins incluídos em wp-content, que pode ter apagado de propósito. Com --quiet, o md5sum mostra apenas os ficheiros que falham.

Sem qualquer saída e com código de saída zero, os ficheiros da lista de checksums filtrada coincidem. Um erro de transferência, de processamento ou de verificação não é um resultado limpo. A subshell usa um diretório temporário privado e pára se um passo anterior falhar.

Este método não deteta ficheiros extra. Para os encontrar, descarregue a mesma versão, por exemplo https://wordpress.org/wordpress-6.8.3.zip. Em instalações que não estejam em inglês, use o site WordPress.org do idioma correspondente. Descompacte o arquivo e compare as pastas:

diff -rq wordpress/wp-includes /var/www/example.com/wp-includes
diff -rq wordpress/wp-admin /var/www/example.com/wp-admin

As linhas Only in /var/www/... identificam ficheiros extra na instalação. As linhas Only in wordpress/... identificam ficheiros em falta na instalação. As linhas Files ... differ identificam diferenças de conteúdo. Inspecione também as pastas inesperadas.

Plugins e temas: onde os checksums deixam de funcionar

O WP-CLI também verifica plugins:

wp plugin verify-checksums --all

Isto só funciona para plugins alojados no WordPress.org, porque só esses têm checksums publicados. Os plugins sem um conjunto de checksums correspondente no WordPress.org não podem ser verificados desta forma.

Se uma cópia pirateada (nulled) ou adulterada mantiver o slug e a versão de um plugin do WordPress.org, o comando consegue na mesma compará-la e assinalará os ficheiros alterados. O WP-CLI não tem um comando integrado equivalente para os checksums de temas.

Para esses plugins e para os temas, obtenha a versão instalada exata a partir da fonte oficial ou de um arquivo de compilação fiável. Para código à medida, use um artefacto de uma versão reconhecidamente boa, não uma cópia retirada do site suspeito. Depois compare-o com a cópia instalada:

diff -rq ~/clean/some-premium-plugin wp-content/plugins/some-premium-plugin

Procure também pastas de plugins que não consegue associar a nada do que instalou. Uma pasta desconhecida em wp-content/plugins é um sinal de alarme. Um plugin nulled é um problema por si só, qualquer que seja o resultado do diff. O guia sobre vulnerabilidades em plugins explica como substituir plugins nulled e abandonados.

Reinstalar o núcleo do WordPress em segurança

Primeiro guarde as provas e faça uma cópia de segurança completa. Depois substitua o núcleo por uma cópia limpa da mesma versão:

wp core download --force --skip-content --version=6.8.3

Se for preciso, acrescente --locale=pt_PT ou o seu idioma. O comando sobrescreve os ficheiros do núcleo. Não toca no wp-config.php, porque o pacote não contém esse ficheiro. A opção --skip-content deixa o wp-content intacto.

O comando não remove ficheiros extra. Um ficheiro como wp-includes/class-wp-cache-handler.php fica onde está, porque a transferência só escreve ficheiros oficiais. Copie e analise primeiro cada ficheiro extra. Depois remova os que forem maliciosos ou que tenha confirmado serem desnecessários. Execute wp core verify-checksums outra vez e confirme que não restam avisos sem explicação.

O que um resultado limpo nos checksums não lhe diz

Um resultado positivo cobre apenas o núcleo do WordPress. Não diz nada sobre:

• wp-content: temas, plugins premium e à medida, mu-plugins e uploads
• wp-config.php e .htaccess, que não constam da lista de checksums
• A base de dados: opções injetadas, spam em artigos, contas de administrador não autorizadas, eventos agendados do cron
• Ficheiros fora do WordPress, como outros ficheiros PHP na conta de alojamento ou a configuração ao nível do servidor

Os atacantes sabem que ficheiros são verificados. É uma das razões por que wp-content/uploads é um local preferido para web shells. Percorra os sinais de um site pirateado para as restantes verificações. Para os uploads, use o guia sobre web shells.

Monitorização contínua da integridade dos ficheiros

Uma verificação pontual ajuda durante um incidente. Uma verificação agendada pode encurtar o tempo em que uma alteração passa despercebida, mas as alterações podem afetar os visitantes antes da execução seguinte. Basta um pequeno script executado pelo cron:

#!/bin/bash
cd /var/www/example.com || exit 1
OUT=$(/usr/local/bin/wp core verify-checksums 2>&1)
if [ $? -ne 0 ] || echo "$OUT" | grep -q "Warning:"; then
  echo "$OUT" | mail -s "Core checksum alert: example.com" admin@example.com
fi

Instale-o no crontab do proprietário do site, não no do root. O script emite um alerta quando o código de saída não é zero e perante qualquer aviso, incluindo ficheiros extra comunicados. Defina um PATH conhecido ou use caminhos completos para os executáveis, porque o cron tem um ambiente limitado. Teste se o alerta chega mesmo; se for preciso, substitua o mail pelo seu sistema de alertas em funcionamento.

Para o wp-content, mantenha a sua própria referência (baseline) depois de cada atualização que sabe estar correta:

find wp-content/plugins wp-content/themes -type f -exec sha256sum {} + > ~/baseline-$(date +%F).sha256

Guarde a baseline fora da raiz web, idealmente fora do servidor. Para verificar alterações, execute sha256sum -c --quiet com a baseline a partir da raiz do site. Isto apanha ficheiros alterados e apagados, mas não os novos. Para os novos, compare uma lista de ficheiros fresca, obtida com find, com a lista da baseline. Crie uma nova baseline depois de cada atualização legítima, ou a verificação seguinte assinalará as suas próprias alterações.

As verificações regulares também apoiam a conformidade. O artigo 32.º, n.º 1, alínea d) do RGPD exige um processo para testar, apreciar e avaliar regularmente as medidas de segurança. Uma verificação de integridade agendada, com os resultados guardados, é uma prova concreta desse processo. Veja o artigo 32.º do RGPD para WordPress para o quadro mais amplo.

Se preferir não manter scripts, o plugin Security Audit & Compliance, da secaudit.eu, mantém uma baseline de integridade de ficheiros e comunica os ficheiros alterados e o conteúdo ofuscado. Também faz a verificação dos checksums do núcleo. Deteta e comunica. A limpeza continua a ser trabalho seu ou da sua agência.

Perguntas frequentes

O verify-checksums funciona em multisite e em instalações que não estão em inglês?

Sim. Uma rede multisite partilha um único conjunto de ficheiros do núcleo, por isso uma execução cobre toda a rede. Em instalações que não estejam em inglês, indique o --locale correto, porque os pacotes localizados podem diferir do en_US.

Um aviso «File should not exist» é sempre malware?

Não. Ficheiros deixados por versões antigas do WordPress também o provocam. Guarde uma cópia e inspecione o ficheiro. Remova-o se for malicioso ou se tiver confirmado que é desnecessário. Código PHP sem explicação numa pasta do núcleo merece sempre uma análise séria.

Com que frequência devo executá-lo?

Diariamente, através do cron, é razoável para a maioria dos sites empresariais. Execute-o também após um incidente, após cada atualização do núcleo e sempre que alguém novo obtiver acesso ao servidor.

Um atacante pode falsificar o resultado dos checksums?

Os próprios checksums vêm do WordPress.org por HTTPS. Mesmo assim, um atacante que controle o seu servidor pode adulterar as ferramentas locais, como o ficheiro do WP-CLI ou os binários do sistema. Em caso de dúvida, copie os ficheiros do site para uma máquina limpa e compare-os lá com uma transferência nova da mesma versão.