php2shell-check

Um script de triagem somente leitura para sites WordPress após o PHP2Shell (CVE-2026-109618 e CVE-2026-109619), o par de bugs críticos de execução remota de código no motor PHP divulgados em 21 de outubro de 2026.

Corrigir o PHP fecha a porta, mas os honeypots da Amazon registraram uma tentativa de exploração em 17 de outubro, quatro dias antes da divulgação pública, enquanto os bugs ainda estavam sob embargo. Essa é a atividade mais antiga que alguém publicou, não o dia em que os ataques começaram, então trate-a como um piso. Qualquer site que estivesse acessível com um PHP não corrigido durante essa janela pode já ter um backdoor, e atualizar o PHP não o removerá. Este script verifica um ou vários sites WordPress em busca das coisas que um atacante com execução de código tipicamente deixa para trás, e grava um relatório Markdown para cada um.

Um terceiro bug, CVE-2026-115560, foi anunciado em 23 de outubro. Ele ainda não tem build corrigida: as versões pontuais de outubro (8.2.35, 8.3.36, 8.4.27, 8.5.12) não o cobrem, e a correção está prevista para a próxima versão regular em novembro. O php.net pede que todos definam session.upload_progress.enabled=0 no php.ini ou no pool do PHP-FPM até lá. O script verifica se isso foi feito.

Ele nunca modifica nem exclui nada. Ele lista, verifica e relata. O que fazer com os achados é com você.

O que ele verifica

Área	Verificação
PHP	Versão da CLI instalada vs. as versões corrigidas (8.2.35, 8.3.36, 8.4.27, 8.5.12). Sinaliza ramificações em fim de vida, que não receberam versão do php.net; veja Ramificações mais antigas do PHP.
Progresso de upload	Se session.upload_progress.enabled=0, a mitigação da CVE-2026-115560, está definida onde importa: na visão do próprio PHP-FPM (php-fpm -i), em cada php.ini legível, conf.d, pool do FPM e configuração do Apache. .user.ini e .htaccess no nível do site são reportados mas não contabilizados, porque o php.net diz que eles não funcionam para esta configuração.
Integridade do núcleo	wp core verify-checksums contra o wordpress.org
Integridade de plugins	wp plugin verify-checksums --all, e lista plugins premium/personalizados que não consegue verificar
Uploads	Qualquer arquivo executável em PHP sob wp-content/uploads (ignora stubs "Silence is golden")
Alterações recentes	Arquivos PHP e de configuração modificados desde o início da janela (padrão 2026-10-17). Pacotes de tradução do WordPress (wp-content/languages/**/*.l10n.php) são contados separadamente depois de passarem num teste de forma estrito; um que falhe nele é sinalizado.
Ganchos de prepend	auto_prepend_file / auto_append_file em .user.ini, .htaccess, php.ini
Plugins must-use	Conteúdo de wp-content/mu-plugins (executa em cada requisição, oculto da lista normal de plugins)
Padrões de código	Assinaturas clássicas de web-shell (eval(base64_decode(...)), $_POST[...](), etc.) em wp-content
Usuários	Todos os administradores, e qualquer conta registrada dentro da janela
Banco de dados	siteurl/home, opções e posts contendo scripts injetados ou código ofuscado
Cron	Eventos agendados do WP-Cron
Logs	Logs de acesso: respostas 5xx por dia para a janela vs. uma linha de base de até 7 dias antes dela, mais as URLs que retornam 5xx na janela. Logs de erro e do PHP-FPM: travamentos de worker (segfault/bus error).
Servidor	O crontab do usuário do site e as authorized_keys do SSH
Docker	Cada contêiner em execução com um binário php: a versão do PHP dentro dele, e se o contêiner ainda executa um build mais antigo que a imagem em disco (baixada mas não recriada)

O WP-CLI é executado com --skip-plugins --skip-themes para que um plugin ou tema com backdoor não possa ser executado enquanto a verificação roda.

Requisitos

Em cada máquina sendo verificada:

• bash 3.2+, find, grep e sort -V (padrão em hosts Linux; também funciona a partir de uma estação de trabalho macOS padrão)
• WP-CLI para as verificações de checksum, usuários e banco de dados. Sem ele, as verificações de sistema de arquivos ainda rodam e o relatório informa o que foi ignorado.
• php no path, para a verificação de versão

Para sites remotos: acesso por chave SSH a partir da máquina onde você executa o script. O script se executa via SSH; nada precisa ser instalado no host remoto além do acima.

Uso

No próprio servidor

curl -O https://raw.githubusercontent.com/brentmartinmiller/php2shell-check/main/php2shell-check.sh
chmod +x php2shell-check.sh

# One site
./php2shell-check.sh /var/www/example.com
less php2shell-reports/*.md

# Every site on the box
printf '%s\n' /var/www/*/public_html > sites.txt
./php2shell-check.sh sites.txt
cat php2shell-reports/SUMMARY.md

Execute-o como o usuário proprietário dos arquivos do site, quando possível. Ele funciona como root (o WP-CLI recebe --allow-root), mas as verificações de crontab e de chave SSH passam então a inspecionar as do root em vez das do usuário web.

A partir da sua estação de trabalho, contra muitos servidores

git clone https://github.com/brentmartinmiller/php2shell-check.git
cd php2shell-check
cp sites.txt.example sites.txt   # edit: one site per line
./php2shell-check.sh sites.txt

Para cada entrada user@host:path, o script conecta-se via SSH, executa-se a si próprio lá e traz o relatório de volta para php2shell-reports/ na sua máquina. Nada é instalado no host remoto. O SSH é executado com BatchMode=yes, pelo que é necessário acesso baseado em chave que funcione sem pedido de palavra-passe.

Alojamento partilhado

A maioria dos hosts partilhados (Hostinger, SiteGround, Bluehost e semelhantes) oferece SSH, mas muitas vezes não tem o wp no path. Verifique com which wp. Se estiver em falta, descarregue o WP-CLI uma vez para o seu diretório home e aponte o script para ele:

curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
WP="php $HOME/wp-cli.phar" ./php2shell-check.sh domains/example.com/public_html

Sem o WP-CLI, as verificações do sistema de arquivos ainda são executadas e o relatório anota o que foi ignorado. De qualquer forma, pergunte diretamente ao provedor de hospedagem quando ele lançou o PHP corrigido, já que essa é a única coisa que uma verificação no nível da conta não consegue ver.

Formato da lista de sites

sites.txt tem um site por linha, seja um caminho local ou user@host:path. Caminhos remotos relativos são relativos ao diretório home do usuário SSH. Linhas que começam com # são ignoradas. Veja sites.txt.example. O arquivo está em .gitignore para que os nomes de host dos clientes não acabem em um commit.

Portas SSH não padrão, chaves e jump hosts pertencem ao ~/.ssh/config:

Host client-a
    HostName 203.0.113.10
    Port 2222
    User deploy
    IdentityFile ~/.ssh/client-a

Em seguida, liste o site como client-a:/var/www/html.

Docker

php -v em um host Docker não diz nada sobre os containers, e baixar uma imagem fixa não corrige nada até que o container seja recriado a partir dela. O site de uma equipe ficou na versão 8.3.35 por três dias após o pull exatamente por esse motivo.

Quando o script é executado em um host onde docker ps funciona, o relatório ganha uma seção Docker containers listando cada container em execução que possui um binário php, a versão do PHP dentro dele e se o container está desatualizado (uma build mais recente da sua imagem está no disco, mas o container nunca foi recriado). Recrie com docker compose up -d, ou pare, remova e execute o container novamente.

Para executar a verificação completa dentro de um container, liste-o como um alvo:

docker:wordpress-php-1:/var/www/html