Voltar ao Blog Manutenção de Sistemas

Vulnerabilidade PHP2Shell: o que fazer e quem resolve

22 OUT 2026 4 min de leitura Mauricio Biasotto
Painel de verificação do PHP2Shell com as três perguntas para a hospedagem (versão do PHP no ar, se é a corrigida, se o servidor foi reiniciado) e a lista de sites da empresa marcados como corrigidos ou expostos

Falha crítica no PHP (PHP2Shell) atinge WordPress, lojas e sistemas internos. O que pedir à hospedagem ou agência, como conferir e quem chamar.

Se você tem um site ou sistema em PHP (WordPress, loja virtual, sistema interno), isso é com você. PHP2Shell é uma falha crítica no PHP, o programa que faz o site funcionar, que permite a um invasor executar o que quiser no servidor, sem senha. A correção saiu em 21 de outubro de 2026, e no mesmo dia já havia tentativas de ataque. A solução é atualizar o PHP para a versão corrigida e reiniciar o servidor; quem está em versão antiga, sem suporte, precisa migrar. O próximo passo é perguntar a quem cuida do site qual versão do PHP está no ar hoje e, se ninguém souber responder, chamar um programador.

Isso é comigo?

Sim, se o site ou sistema roda em PHP. A falha não está em um plugin, em um tema nem em um sistema específico: está no próprio PHP, por trás do WordPress, das lojas virtuais e dos sistemas internos. Vale para qualquer versão desde o PHP 5, de 2004 para cá.

Em WordPress, atualizar plugins e temas não resolve: a correção é no PHP do servidor, tarefa de quem cuida da hospedagem, não de quem edita o site.

Se ninguém na empresa sabe em que versão do PHP o site roda, a resposta está a uma pergunta de distância.

O que acontece se eu não fizer nada?

Um invasor que explore a falha executa o que quiser no servidor, sem senha: pode ler dados que estão lá, alterar o site ou tirá-lo do ar.

Os detalhes vazaram em 20 de outubro, um dia antes da correção. Pesquisadores esperam ataques automáticos em massa: programas que varrem a internet inteira, sem escolher alvo.

Em versão com suporte, isso se resolve em horas. Em versão antiga, não existe correção: a falha é permanente até a migração.

Quem resolve: a hospedagem, a agência ou um programador?

Depende de onde o site está:

Site em plano de hospedagem. Quem atualiza o PHP é a hospedagem. A empresa pede e confere.
Agência cuida do site. A agência coordena com a hospedagem ou com o programador dela. As três perguntas abaixo valem para ela.
Servidor próprio ou contratado só para a empresa. Quem administra o servidor atualiza. Se não existe ninguém com esse papel, é aqui que entra um programador PHP para corrigir e atualizar o sistema.

O que eu peço, e como confiro que foi feito?

Três perguntas, por escrito, para a hospedagem, a agência ou o programador:

1. Qual é a versão exata do PHP que está no ar hoje? Número completo, com três partes (8.3.36), não só "8.3".
2. Essa versão é a corrigida? A tabela abaixo responde.
3. O servidor foi reiniciado depois da atualização?
Seu site está emVersão corrigida
PHP 8.48.4.27
PHP 8.38.3.36
PHP 8.28.2.35
PHP 8.1 ou anteriorSem correção: precisa migrar

Versão igual ou mais nova que a da tabela está corrigida.

A resposta que vale é a versão em produção, conferida no site real, não a que aparece no painel da hospedagem: uma coisa pode estar marcada lá e outra rodando no site.

A terceira pergunta não é detalhe: a atualização só passa a valer depois que o servidor é reiniciado, e isso não acontece sozinho em todo lugar, como lembra o aviso de segurança do Laravel Forge, serviço usado para administrar servidores. Sem reinício, o site segue vulnerável com a versão nova instalada.

E se a resposta for "seu site está em PHP 7"?

Para PHP 5, 7, 8.0 e 8.1 não existe versão corrigida: a equipe do PHP não publica mais correções para elas. Vale perguntar se a hospedagem tem correção própria; se não, o caminho é a migração.

Migração não é atualização. É um projeto com começo, meio e fim: testar o sistema na versão nova, ajustar o que deixou de funcionar e colocar no ar, trabalho de um desenvolvedor Laravel para modernizar sistemas PHP. O alvo deve ser o PHP 8.3 ou 8.4, não o 8.2: o PHP 8.2 deixa de receber correções de segurança em 31 de dezembro de 2026, e migrar para ele agora só adia o problema. Para decidir entre migrar e refazer, o critério está em quando modernizar um sistema PHP antigo.

Enquanto a migração não acontece, o sistema fica restrito à rede da empresa ou fora do ar: o NCSC, centro de segurança cibernética do Reino Unido, orientou considerar tirar do ar o que não puder ser corrigido rápido.

Quanto tempo leva e como é cobrado?

O trabalho inclui:

Levantamento da versão do PHP de todos os sites e sistemas da empresa, inclusive os esquecidos.
Atualização e reinício do servidor, com cópia de segurança antes, direto ou junto à hospedagem e à agência.
Conferência no site real, com a versão por escrito.
Verificação de sinais de invasão.
Plano de migração, com etapas e prazo, quando a versão é antiga demais para corrigir.

A empresa recebe um registro curto, por escrito: qual versão estava, qual está agora, quando o servidor foi reiniciado e o que ficou pendente. Para sites em versão com correção, o prazo é de horas; com vários sistemas ou hospedagens diferentes, alguns dias. A migração é projeto à parte, com prazo definido após avaliar o sistema.

O trabalho é feito por demanda ou dentro de um plano de manutenção de sistemas e sites em PHP e Laravel, que já inclui esse tipo de atualização antes da emergência. Ter alguém responsável pelo site é o que separa resolver em horas de descobrir depois do estrago; é para isso que serve uma rotina de manutenção mensal.

Para começar hoje, basta mandar o endereço do site no WhatsApp (ou o nome da hospedagem). Com isso já dá para dizer por onde começar e o que pedir.

PRÓXIMO PASSO_

Seu site ou sistema já está corrigido contra o PHP2Shell?

Utilizamos cookies para otimizar sua experiência de navegação de acordo com a nossa política de privacidade.