wp2shell-scan

Detecte e limpe o comprometimento do wp2shell (CVE‑2026‑63030) em um ou vários sites WordPress.

O wp2shell é a vulnerabilidade de execução remota de código pré‑autenticação corrigida no WordPress 7.0.2 / 6.9.5 / 6.8.6 (2026‑07‑17). Um PoC público surgiu em menos de um dia e a exploração em massa veio em cerca de 48 horas. A aplicação do patch fecha a brecha — mas um site explorado antes de ser corrigido já está comprometido, e a atualização não remove a persistência do atacante.

Esta ferramenta encontra e remove essa persistência. É um único script Bash com poucas dependências que é executado somente leitura por padrão e pode escanear milhares de sites em uma única passagem.

⚠️ Esta é uma ferramenta defensiva. Ela não contém código de exploit. Tire um snapshot do site antes de executar --clean.

O que ele detecta

Após a exploração, as ferramentas do wp2shell normalmente deixam dois artefatos de persistência, ambos encontrados por esta ferramenta:

1. Um administrador malicioso — várias variantes observadas: user_login = wpsvc_<hex> / wp2_<hex> / w2s_<hex>, ou um e‑mail em um domínio do atacante (@wp2shell.*, @shellcode.*, @wordpress-svc.internal, @wordpress-noreply.net, @x.lol), com a função administrator. (Nota: @system.local é um e‑mail de administrador legítimo de placeholder em alguns hosts gerenciados — ele deliberadamente não é tratado como um IOC.)
2. Um webshell disfarçado de plugin — wp-content/plugins/<nome-plausível>-<6hex>/<mesmo>.php: um arquivo PHP minúsculo (~1,3 KB) com um cabeçalho falso Author: WordPress.org Community, protegido por um token, expondo uma interface ?c=<command>.

Ele também detecta o caso genérico: qualquer arquivo PHP pequeno sob wp-content/ que canaliza $_GET['c'] para um sink de comando/eval.

Instalação

curl -fsSLO https://raw.githubusercontent.com/InstaWP/wp2shell-scan/main/wp2shell-scan.sh
chmod +x wp2shell-scan.sh

Requer bash, find, grep e um cliente mysql/mariadb. O WP‑CLI é usado quando presente (exclusão de usuário mais limpa), mas não é obrigatório — a detecção de webshell não precisa de banco de dados algum.

Uso

# Scan ONE site (read-only)
./wp2shell-scan.sh --path /var/www/example.com

# Scan EVERY WordPress install under a base directory (bulk)
./wp2shell-scan.sh --base /var/www
./wp2shell-scan.sh --base /home            # shared hosting

# Auto-detect common layouts (/var/www/*, /home/*/public_html, ...)
./wp2shell-scan.sh

# Machine-readable
./wp2shell-scan.sh --base /var/www --json > report.json

# CLEAN — quarantine + remove backdoors, rotate wp-config salts (logs everyone out)
./wp2shell-scan.sh --base /var/www --clean --yes

# Vet a BACKUP / SNAPSHOT / TEMPLATE dump before restoring it (see warning below)
./wp2shell-scan.sh --sql /path/to/backup.sql

Artefatos removidos são movidos para um diretório de quarentena (não excluídos de imediato) para que você mantenha as evidências. O código de saída é 1 quando um comprometimento é encontrado (scan) ou limpo (clean), 0 quando limpo — útil para cron/CI.

Exemplo de saída

[COMPROMISED] /var/www/example.com  — 2 backdoor admin(s), 2 webshell(s)
      admin: ID=41 wpsvc_2e1487df8abb <[email protected]> (2026-07-19 06:41:48)
      webshell: .../wp-content/plugins/security-headers-manager-8d1d21/security-headers-manager-8d1d21.php
[clean] /var/www/other-site.com
----------------------------------------------------------------
scanned=812  clean=811  compromised=1  cleaned=0

⚠️ Não se esqueça dos seus backups, snapshots e templates

Limpar um site ativo NÃO limpa os seus backups. Um backup, snapshot ou template de staging/blueprint capturado enquanto o site estava comprometido ainda contém a conta de administrador do atacante — restaurá-lo (ou provisionar um novo site a partir dele) reinfecta instantaneamente. Aprendemos isso da forma difícil: depois de limpar todos os sites ativos afetados, novos sites continuavam a aparecer com a backdoor porque estavam a ser provisionados a partir de um snapshot de template envenenado.

Verifique um dump antes de o restaurar:

./wp2shell-scan.sh --sql /path/to/backup.sql
./wp2shell-scan.sh --sql backup1.sql --sql backup2.sql.gz   # repeatable, .gz supported

O código de saída é 1 se qualquer dump estiver envenenado. Se estiver: não o restaure — limpe primeiro o site em produção, depois faça um backup novo e apague/substitua qualquer snapshot ou template criado durante a sua janela de exposição.

Após a limpeza

--clean remove o admin + webshell e roda os salts. Você ainda precisa:

1. Atualizar o core do WordPress para 7.0.2 / 6.9.5 / 6.8.6 (a correção real).
2. Redefinir todas as senhas de admin e reinstalar/verificar o core + plugins (wp core verify-checksums).
3. Rodar quaisquer segredos que o site conseguia ler — senha do BD, chaves de API, credenciais SMTP — assuma que vazaram.
4. Revisar o que o shell executou — seus logs de acesso registram os valores dos comandos ?c=.
5. Bloquear a rota de batch na sua borda/origem até que todos os sites estejam corrigidos (/wp-json/batch/v1, ?rest_route=/batch/v1, incl. codificado com %2f). Coloque na origem se um CDN puder liberar o caminho REST.

Verificar manualmente (sem ferramenta)

Admins maliciosos:

SELECT u.ID,u.user_login,u.user_email,u.user_registered
FROM wp_users u JOIN wp_usermeta m ON u.ID=m.user_id
WHERE m.meta_key='wp_capabilities' AND m.meta_value LIKE '%administrator%'
ORDER BY u.user_registered DESC;

Plugins de webshell:

find wp-content/plugins -maxdepth 1 -type d -regextype posix-extended -regex '.*-[0-9a-f]{6}$'
grep -rl "\$_GET\['c'\]" wp-content/plugins/

Prefere um agente de IA?

Consulte CLEANUP-WITH-CLAUDE.md para obter um prompt pronto para colar que orienta o Claude Code (ou qualquer agente de programação capaz) pela mesma detecção e limpeza em um único site, com confirmação humana antes de cada etapa destrutiva.

Licença

MIT — consulte LICENSE. Fornecido como está, sem garantia. Construído e testado em batalha durante um incidente real pela equipe da InstaWP.