Backdoor no WordPress se reconstrói após limpeza
Um backdoor no WordPress apelidado de SC foi descrito por pesquisadores da Sucuri como uma malha de persistência capaz de se reconstruir após uma limpeza parcial. Segundo o relato The Hacker News, o malware mantém cópias em arquivos, banco de dados e memória compartilhada, usa a blockchain Ethereum para comunicação com um servidor C2 e pode devolver o controle do site ao invasor.
O caso afeta administradores, agências e provedores: apagar um único plugin não basta quando a infecção foi projetada para restaurar seus próprios componentes.
O principal risco é a reinfeção: uma cópia sobrevivente pode recriar todas as outras no próximo carregamento da página ou em uma tarefa agendada.
Como o malware SC mantém o controle do site
O backdoor no WordPress não depende de um único arquivo. A Sucuri identificou ao menos oito peças que se apoiam mutuamente. Entre elas estão o arquivo .user.ini, configurado com auto_prepend_file para executar código antes das requisições PHP; loaders ocultos em wp-content; os drop-ins db.php e advanced-cache.php; um arquivo functions.php no tema; e cópias do payload como plugin convencional e plugin must-use em mu-plugins.
- Arquivos ocultos: loaders dot-prefixed e cópias em plugins.
- Banco de dados: payload comprimido e codificado em Base64.
- Memória RAM: segmento System V compartilhado entre processos.
- Tema ativo: função capaz de recriar o plugin malicioso.
- Agendamento: hooks de WordPress cron para restaurar componentes.
Por que a memória compartilhada muda a limpeza
Em servidores compatíveis, o SC pode gravar PHP em um segmento System V. Como esse conteúdo permanece na RAM, apagar arquivos e limpar o banco de dados pode não encerrar a persistência sem reiniciar, isolar e investigar corretamente o ambiente.
Capacidades e sinais de um backdoor no WordPress
De acordo com a pesquisa atribuída à Sucuri, o malware oculta sua presença na tela de plugins e nas verificações de atualização, identifica características do site comprometido, busca cargas adicionais e pode criar uma conta administradora oculta. Também seria capaz de executar PHP, desativar plugins específicos e baixar JavaScript arbitrário para atingir visitantes — cenário compatível com a instalação de skimmers e outras ameaças no navegador.
| Área | Indicador | Ação inicial |
|---|---|---|
| wp-content | Arquivos com ponto ou nomes aleatórios | Preservar cópia para análise |
| Plugins | hyper-engine-kit em duas rotas | Não apagar antes de coletar evidências |
| Configuração PHP | .user.ini com auto_prepend_file | Revisar diretórios afetados |
| Administração | Usuário desconhecido com privilégios | Revogar acesso e investigar logs |
“Uma infecção moderna em WordPress pode ser um sistema, e não um arquivo.”
Sucuri, em análise técnica citada pelo The Hacker News; tradução livre.
Resposta segura: o que fazer diante da reinfeção
Trate um backdoor no WordPress que retorna como incidente de comprometimento amplo. Antes de remover conteúdo, coloque o site em manutenção quando possível, restrinja acessos e preserve evidências: logs do servidor, logs PHP, lista de processos, tarefas cron, banco de dados e uma imagem dos arquivos. Em hospedagem compartilhada, acione o provedor para verificar processos, contas vizinhas e segmentos de memória compartilhada.
- Crie backup forense, separado do backup de restauração.
- Rotacione senhas, chaves, tokens e sessões administrativas.
- Compare o core do WordPress com versões oficiais íntegras.
- Audite
mu-plugins, temas, drop-ins e o banco de dados. - Remova código não confiável e restaure apenas backup comprovadamente limpo.
- Atualize core, temas e plugins; mantenha monitoramento reforçado.
Uma reinstalação controlada em ambiente limpo costuma ser mais confiável que a exclusão seletiva de arquivos, especialmente quando há indícios de web shell, alteração de tema ou persistência no banco. A validação deve incluir teste de integridade, revisão de usuários, busca por código ofuscado e monitoramento de requisições de saída para domínios suspeitos.
Falha no wpForo também está sob exploração
O alerta também menciona a CVE-2026-1581, uma SQL injection não autenticada de alta severidade no plugin wpForo Forum, com CVSS 7,5. O problema afetaria versões até a 2.4.14. Dados de telemetria da Previdian, citados na reportagem original, registraram menos de 20 tentativas desde 3 de julho de 2026, originadas de cinco endereços IP. O volume limitado não reduz a urgência: administradores devem atualizar ou aplicar a mitigação oficial imediatamente e revisar exposições anteriores.
Considerações finais
O caso SC mostra por que um backdoor no WordPress exige investigação além do diretório de plugins. Persistência em arquivos, banco de dados, memória compartilhada e cron pode transformar uma limpeza simples em reinfeção contínua. A prioridade é conter, coletar evidências, reconstruir o ambiente com fontes confiáveis e eliminar a causa inicial do acesso indevido.
O que é o malware SC no WordPress?
É um backdoor persistente. Ele mantém cópias em arquivos, banco de dados e memória para restaurar o código removido. A análise foi publicada pela Sucuri e repercutida pelo The Hacker News.
Por que o backdoor no WordPress volta após a limpeza?
Porque uma cópia sobrevivente recria as demais. O SC usa loaders, drop-ins, tema, plugin must-use, banco de dados e, em alguns servidores, memória System V. Limpar só um arquivo não interrompe o ciclo.
Quais arquivos devem ser auditados em uma reinfeção?
Priorize .user.ini, db.php, advanced-cache.php, functions.php, mu-plugins e plugins desconhecidos. Verifique também usuários administradores, tarefas cron, código Base64 ofuscado e logs PHP antes de excluir evidências.
A CVE-2026-1581 do wpForo exige atualização?
Sim. A falha é uma SQL injection não autenticada com CVSS 7,5 e afeta versões até 2.4.14, segundo o alerta. Atualize o wpForo ou aplique a orientação oficial e revise os registros de acesso.
Fontes: CVE, Previdian, Pesquisador
