PHP2Shell: o que fazer além de atualizar o PHP
As falhas PHP2Shell permitem rodar código em servidores PHP sem login. Veja quem está exposto, como atualizar, o que fazer no PHP 8.1 ou anterior e como checar invasão.
Camillo Rinaldi 5 min de leitura 
Neste artigo 7 seções
Em 21 de outubro de 2026, o projeto PHP publicou versões de emergência para corrigir duas falhas críticas, a CVE-2026-109618 e a CVE-2026-109619, que ficaram conhecidas como PHP2Shell. Segundo o próprio PHP, elas permitem execução remota de código sem autenticação: alguém de fora, sem login nem senha, consegue rodar comandos no servidor.
No Brasil, o efeito foi visível em poucas horas. A Anatel tirou do ar temporariamente o SEI, o sistema eletrônico de informações, e informou que a causa era a vulnerabilidade recente do PHP, não uma falha do SEI em si. O TRF1 suspendeu o acesso externo ao SEI dele, e a Justiça Federal da 4ª Região interrompeu o acesso aos sistemas digitais.
Atualizar o PHP é o primeiro passo, e o mais urgente. Mas não é o único: quem esteve exposto antes da atualização precisa conferir se o servidor não foi comprometido nesse intervalo. Abaixo está o que fazer, na ordem.
Quem está exposto
O aviso do PHP diz que estão em risco todas as instalações do PHP que atendem requisições web, incluindo PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. O risco é considerado maior no mod_php, em que uma requisição sem autenticação dispara o ataque antes de qualquer código da aplicação rodar.
Isso vale para qualquer coisa escrita em PHP: WordPress, Joomla, Moodle, Magento, Drupal, sistemas internos em Laravel ou PHP puro. Atualizar o WordPress ou os plugins não resolve, porque a falha está no próprio PHP, e não no código do site.
1. Descubra a versão do PHP que o site usa
As versões corrigidas são estas:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
Para saber qual você usa:
- No WordPress: Ferramentas > Saúde do site > Informações > Servidor. Lá aparecem a versão do PHP e o modo em que ele roda.
- Em hospedagem compartilhada: o painel da hospedagem costuma mostrar a versão. Se não mostrar, pergunte ao suporte.
- Em servidor próprio: cuidado com o
php -vno terminal. Ele mostra a versão da linha de comando, que pode não ser a mesma do PHP que atende o site (o FPM ou o módulo do Apache). Confira a versão que o servidor web usa de fato.
2. Atualize, e veja se a sua versão ainda recebe correção
Se você está no PHP 8.2 ou mais novo, basta ir para a versão corrigida da sua linha. Em hospedagem compartilhada, quem faz isso é o provedor: abra um chamado e peça a confirmação por escrito.
Se você está no PHP 8.1 ou anterior, a situação é outra. O projeto PHP não publica mais versões para essas linhas. Ele disponibilizou patches mínimos de código-fonte para o 7.4, o 8.0 e o 8.1, para quem compila o PHP por conta própria, e algumas distribuições Linux e fornecedores de suporte estendido oferecem correções próprias. Fora isso, o caminho é migrar para uma versão suportada.
E um aviso para quem acabou de atualizar para o 8.2: segundo o projeto PHP, essa linha chega ao fim da vida em 31 de dezembro de 2026 e não receberá mais correções de segurança depois dessa data. Na próxima falha, ela vai estar do lado de fora.
3. Se não dá para atualizar hoje, reduza a exposição
O aviso do PHP lista medidas que reduzem caminhos específicos de ataque, e deixa claro que elas não tornam a instalação segura: só a atualização resolve. Servem para ganhar algumas horas, não para adiar a atualização. Entre elas:
- desligar o
session.upload_progress.enabled(valor 0) e reiniciar todos os workers, numa configuração que valha antes de a requisição ser processada, como ophp.iniou o pool do FPM, e não comini_set(); - usar um
post_max_sizebaixo, de 8M para aplicações sem upload de arquivo ou 32M quando há upload, com oupload_max_filesizeabaixo dele; - no PHP 8.5, desligar o
fatal_error_backtracese reiniciar os workers.
O aviso traz ainda uma orientação sobre o memory_limit e avisa que esconder mensagens de erro com display_errors ou @ não ajuda. Leia o texto completo antes de mexer na configuração de produção.
4. Depois de atualizar, confira se o servidor não foi comprometido
Este é o passo que costuma ficar para trás. Os detalhes das falhas vazaram antes da correção oficial, e empresas de segurança relataram tentativas de exploração logo depois da divulgação. Se o seu servidor ficou exposto nesse intervalo, a atualização fecha a porta, mas não tira quem já entrou.
Numa invasão desse tipo, o atacante costuma deixar um webshell: um arquivo PHP escondido no meio da aplicação que funciona como painel de controle do servidor, e que continua lá depois do patch. Alguns sinais para procurar:
- arquivos
.phpcriados ou modificados desde o dia 20 de outubro, principalmente em pastas que não deveriam ter código, como a de uploads do WordPress (wp-content/uploads); - arquivos com nomes que imitam os do sistema, mas em lugares estranhos;
- código ofuscado, com
eval,base64_decode,gzinflate,assertou chamadas asystem,shell_execepassthruem arquivos que você não reconhece; - usuários administradores novos no WordPress ou no sistema, e tarefas agendadas (cron) que ninguém criou;
- nos logs de acesso, requisições POST para arquivos que não fazem parte da aplicação.
Se o código está num repositório Git, compare o que está no servidor com o que está versionado: qualquer arquivo a mais é suspeito. Se achar algo, a forma mais segura de limpar é reinstalar a aplicação a partir de uma cópia limpa, em vez de apagar arquivo por arquivo, e trocar todas as senhas e chaves que o servidor conhecia: banco de dados, chaves de API, contas de administrador.
O problema de fundo: sistema parado em versão antiga
A PHP2Shell não é a primeira falha grave em uma tecnologia muito usada, e não vai ser a última. O que ela deixa claro é uma regra simples: a correção sai para as versões suportadas. Quem roda PHP 7.4, Node.js 20 ou qualquer outra versão fora de suporte depende de remendo, de fornecedor ou de sorte.
Na KXP, ajudamos empresas a tirar sistemas do fora de suporte sem parar a operação: levantamos o que está desatualizado, priorizamos o que oferece mais risco e modernizamos módulo por módulo, com o sistema no ar. Se o seu sistema em PHP ficou para trás, vamos conversar.
