Remover malware do WordPress: plano passo a passo

Remover malware do WordPress de forma fiável significa substituir tudo o que for possível por cópias de fontes fidedignas, fechar a falha por onde o atacante entrou e mudar todos os segredos a que possa ter tido acesso. Apagar o único ficheiro suspeito que encontrou não chega, porque os atacantes costumam deixar mais do que uma porta de regresso.

Este plano tem oito passos. Siga-os por ordem e vá tomando notas: vai precisar delas para o Google, para o fornecedor de alojamento e, eventualmente, para a autoridade de proteção de dados. Se ainda não tem a certeza de que o site foi comprometido, comece pelos nossos 12 sinais de um WordPress pirateado.

Antes de remover o malware do WordPress: limpar, repor ou pedir ajuda?

Decida isto primeiro, porque muda o resto do plano.

• Reponha uma cópia de segurança limpa se souber aproximadamente quando começou a infeção e tiver uma cópia anterior a essa data. Os passos 3, 5 e 6 continuam a ser necessários, ou o atacante volta a entrar pela mesma falha. Encomendas, comentários ou mensagens de formulários criados depois da cópia perdem-se, a menos que os exporte primeiro.
• Chame um profissional se o site recebe pagamentos ou guarda dados sensíveis, se a infeção voltou depois de uma limpeza anterior, se há vários sites afetados no mesmo servidor, se precisa de um relatório forense para uma seguradora ou uma autoridade, ou se não se sente à vontade na linha de comandos. Muitos fornecedores de alojamento também prestam este serviço.
• Faça a limpeza por conta própria se tiver acesso SSH e WP-CLI, uma lista dos plugins e temas que usa e tempo para o fazer como deve ser.

Conter: travar os danos e guardar as provas

Passo 1: Conter os danos

Coloque o site offline ou restrinja o acesso, para que os visitantes não sejam infetados. wp maintenance-mode activate mostra aos visitantes um aviso de manutenção, mas só afeta os pedidos que carregam o WordPress: um ficheiro de backdoor chamado diretamente continua a funcionar. A verdadeira contenção faz-se no servidor, por isso peça ao fornecedor de alojamento que bloqueie o acesso público ou que o limite ao seu endereço IP.

Depois, feche a área de administração. Este comando termina a sessão de todos os utilizadores:

wp user list --field=ID | xargs -n 1 wp user session destroy --all

Mude a sua própria palavra-passe de administrador a partir de um dispositivo limpo. Tome nota das contas desconhecidas, mas só as apague depois do passo 2. Num site infetado, pode acrescentar --skip-plugins --skip-themes aos comandos do WP-CLI para que o código dos plugins e dos temas não seja executado; os plugins must-use e o wp-config.php continuam a ser carregados.

Passo 2: Fazer um snapshot do estado infetado

Antes de mudar seja o que for, guarde o site pirateado exatamente como está: vai precisar dele para encontrar o ponto de entrada, para responder a uma seguradora ou a uma autoridade e como recurso caso a limpeza estrague alguma coisa.

# executar na raiz do WordPress; ~/evidence deve ficar fora da raiz web
mkdir -p ~/evidence
wp db export ~/evidence/db-infected-$(date +%F).sql
tar -czf ~/evidence/files-infected-$(date +%F).tar.gz .
sha256sum ~/evidence/*

A linha sha256sum regista somas de verificação, para mais tarde poder demonstrar que as cópias não foram alteradas. Descarregue também os registos de acesso e de erros; muitos fornecedores guardam-nos apenas durante um período limitado.

Limpar: fechar a falha e substituir o que foi tocado

Passo 3: Encontrar o ponto de entrada

Quem salta este passo arrisca-se a limpar o mesmo site outra vez na semana seguinte. Os pontos de entrada típicos são plugins ou temas vulneráveis, palavras-passe roubadas ou reutilizadas e outros sites infetados na mesma conta de alojamento.

• Plugins e temas vulneráveis. Execute wp plugin list --fields=name,status,version,update e wp theme list e procure cada item desatualizado numa base de dados de vulnerabilidades. A rapidez conta: a empresa de segurança Patchstack indica que, em 2025, nas vulnerabilidades mais exploradas, a mediana ponderada do tempo até à exploração em massa foi de 5 horas (State of WordPress Security in 2026).
• Credenciais roubadas. Verifique quando foram criadas as contas de administrador desconhecidas e procure inícios de sessão a partir de endereços IP estranhos.
• Registos do servidor. Procure pedidos POST para ficheiros invulgares por volta da hora a que foi alterado o primeiro ficheiro.

grep '"POST ' access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20
find . -type f -name '*.php' -mtime -14 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort

Substitua access.log pelo seu próprio ficheiro de registo. O primeiro comando lista os caminhos que receberam mais pedidos POST; o segundo, os ficheiros PHP alterados nos últimos 14 dias. As datas e horas podem ser falsificadas, por isso trate-as como pistas. Se não encontrar o ponto de entrada, parta do pior cenário: substitua todos os plugins e temas e renove todas as credenciais.

Passo 4: Limpar a partir de fontes fidedignas

Substituir em vez de reparar: cópias novas a partir da fonte oficial são mais fiáveis do que tentar ler código ofuscado.

Núcleo do WordPress. Apague wp-admin e wp-includes e descarregue de novo a mesma versão, para que também desapareçam ficheiros extra escondidos nessas pastas. Execute isto na raiz do WordPress, a pasta que contém wp-load.php e wp-admin:

VER=$(wp core version)
[ -n "$VER" ] && [ -f wp-load.php ] && rm -rf wp-admin wp-includes && \
  wp core download --version="$VER" --skip-content --force
wp core verify-checksums --include-root

A segunda linha não apaga nada a menos que tenha sido encontrada uma versão e que esteja na raiz do WordPress. A opção --include-root (WP-CLI 2.8 ou posterior) lista também os ficheiros desconhecidos na pasta raiz.

Plugins e temas. Substitua cada pasta de plugin e de tema por uma cópia nova do WordPress.org ou da área de transferências do fornecedor. Nos plugins do WordPress.org, wp plugin install <slug> --force substitui a cópia instalada; wp plugin verify-checksums --all indica depois os ficheiros alterados e acrescentados. Apague tudo o que não usa e nunca reinstale a partir de uma cópia "nulled" (pirata).

Uploads. Os uploads não se podem reinstalar, por isso têm de ser inspecionados: procure ficheiros PHP com find wp-content/uploads -type f -iname '*.php', compare a pasta com uma cópia de segurança anterior à infeção e retire tudo o que não sejam ficheiros multimédia.

Configuração e drop-ins. Verifique à mão o wp-config.php, o .htaccess, o .user.ini, a pasta wp-content/mu-plugins e os drop-ins, como o object-cache.php.

Base de dados. O malware também se instala em artigos, opções, utilizadores e eventos agendados:

wp user list --role=administrator --skip-plugins --skip-themes
wp option get siteurl && wp option get home
wp db search '<script' --all-tables
wp cron event list --fields=hook,next_run_relative,recurrence

O wp db search também encontra scripts legítimos, como fragmentos de código de estatísticas. Apague administradores desconhecidos, artigos de spam e opções injetadas só depois de verificar cada um.

Passo 5: Renovar todas as credenciais e os salts

Parta do princípio de que o atacante leu o wp-config.php e todos os segredos guardados no servidor. Mude:

• todas as contas do WordPress com permissões de administrador ou de editor, e revogue as Application Passwords (palavras-passe de aplicação) que não reconheça;
• o painel de controlo do alojamento, o SFTP/FTP e o SSH, incluindo as chaves SSH autorizadas;
• a palavra-passe da base de dados, no alojamento e no wp-config.php ao mesmo tempo;
• as chaves de API guardadas em plugins: pagamentos, SMTP, armazenamento das cópias de segurança, CDN;
• a conta de e-mail que recebe as reposições de palavra-passe dos administradores.

Em seguida, substitua as chaves de autenticação e os salts no wp-config.php. Segundo a documentação para programadores do WordPress, alterá-los invalida todos os cookies existentes, pelo que toda a gente tem de voltar a iniciar sessão, incluindo um atacante com uma sessão roubada.

wp config shuffle-salts

Acompanhamento: reforçar, monitorizar, documentar

Passo 6: Reforçar a segurança do site

• Atualize o núcleo, os plugins e os temas; o nosso guia sobre plugins WordPress vulneráveis trata de auditorias e de atualizações automáticas.
• Acrescente define( 'DISALLOW_FILE_EDIT', true ); ao wp-config.php para retirar os editores de ficheiros do painel. O DISALLOW_FILE_MODS vai mais longe e bloqueia também as atualizações pelo painel e as automáticas, por isso só o deve usar se atualizar de outra forma.
• Ative a autenticação de dois fatores para todos os administradores. O núcleo do WordPress não a inclui.
• Bloqueie a execução de PHP nos uploads. Em Apache 2.4, no ficheiro wp-content/uploads/.htaccess:

<FilesMatch "\.(?i:php|phtml|phar)$">
    Require all denied
</FilesMatch>

Em nginx, coloque esta regra antes do bloco geral location ~ \.php$, porque o nginx usa a primeira location com expressão regular que corresponda ao pedido:

location ~* ^/wp-content/uploads/.*\.(php|phtml|phar)$ { deny all; }

Execute nginx -t antes de recarregar e confirme depois que as imagens continuam a carregar.

Passo 7: Monitorizar e pedir revisões

Acompanhe o site de perto nas semanas seguintes: repita as verificações das somas de verificação e dos uploads, compare as listas de ficheiros com o estado limpo e leia os registos de acesso. Se a infeção voltar, o ponto de entrada continua aberto, e esse é o momento de chamar um profissional.

O Security Audit & Compliance da secaudit.eu pode apoiar esta fase: mantém uma linha de base de integridade dos ficheiros, verifica as somas de verificação do núcleo e procura administradores ocultos, eventos cron suspeitos e spam SEO oculto. Deteta e reporta; não limpa o site por si.

Se o Google tiver assinalado o site, abra Problemas de segurança na Search Console quando tudo estiver limpo, escolha Request a review (pedir revisão) e descreva o que corrigiu. Segundo o Google, as revisões demoram cerca de um dia no caso de phishing, alguns dias no caso de malware e até várias semanas no caso de spam em sites pirateados. Só peça a retirada das listas de bloqueio de correio depois de o spam ter parado.

Passo 8: Avaliar a violação de dados à luz do RGPD e documentá-la

Este passo aparece em último lugar na lista, mas o prazo começa a contar logo no primeiro dia. Se dados de clientes, contas de utilizador, mensagens de formulários ou encomendas foram expostos, alterados ou ficaram indisponíveis, o ataque constitui normalmente uma violação de dados pessoais. Nesse caso, tem de notificar a autoridade de controlo (em Portugal, a CNPD) sem demora injustificada e, sempre que possível, no prazo de 72 horas após ter tido conhecimento, a menos que a violação não seja suscetível de resultar num risco (art. 33.º do RGPD). Se o risco para as pessoas for elevado, tem também de as informar (art. 34.º).

Seja qual for a decisão, documente os factos, os efeitos e as medidas de reparação adotadas: o art. 33.º, n.º 5, exige-o para todas as violações, mesmo as que não são notificadas. O nosso guia sobre a notificação de violações em 72 horas explica a avaliação passo a passo. Se a organização estiver abrangida pela Diretiva NIS2, os incidentes significativos exigem também um alerta precoce no prazo de 24 horas; consulte a lei nacional de transposição da NIS2 no seu país.

Perguntas frequentes

Um plugin de segurança pode remover o malware por mim?

Algumas ferramentas oferecem limpeza automática de malware conhecido. Nenhuma consegue dizer com certeza como o atacante entrou ou que palavras-passe levou, por isso os passos 3, 5 e 6 continuam a ser trabalho seu.

Reinstalar o núcleo do WordPress apaga o meu conteúdo?

Não. Os artigos, as páginas e as definições ficam na base de dados e, com --skip-content, os plugins, os temas e os uploads não são tocados. Só são substituídos os ficheiros do núcleo em wp-admin, em wp-includes e na pasta raiz; o wp-config.php mantém-se.

Este artigo contém informação geral e não constitui aconselhamento jurídico.