Sua loja continua recebendo pedidos, mas chegou um alerta dizendo que uma falha no PHP permite executar código no servidor sem senha. A hospedagem responde que está verificando. Você precisa decidir se mantém a operação aberta, só que ainda não sabe qual versão roda ali. Essa é a decisão prática por trás do PHP2Shell: descobrir a exposição da empresa e cobrar uma correção verificável.
Apuração em 22 de outubro de 2026. As correções foram publicadas em 21/10. Os números de versão abaixo registram essa publicação; ao atualizar depois dessa data, consulte também as versões posteriores disponibilizadas pelo seu fornecedor.
O que aconteceu com o PHP2Shell
PHP2Shell é o nome pelo qual ficaram conhecidas duas vulnerabilidades críticas no mecanismo que executa aplicações PHP. Elas foram registradas como CVE-2026-109618 e CVE-2026-109619. Nas condições descritas pelos pesquisadores, permitem execução remota de código sem autenticação. Os avisos oficiais detalham a falha por corrupção de memória e a falha por reutilização de estado interno.
Para quem administra o negócio, a consequência possível é alguém executar instruções com as permissões do processo PHP. O alcance depende dos acessos desse processo: arquivos da aplicação, credenciais disponíveis no ambiente e serviços que ele consegue alcançar precisam entrar na avaliação técnica. Não significa acesso automático a todos os computadores da empresa.
Também não significa que todo site com PHP foi invadido. Uma vulnerabilidade é uma condição que pode permitir um ataque. Confirmar que alguém a explorou exige investigação do ambiente afetado.
O que vazou, e por que isso não comprova roubo de código
Segundo o relato da PHP Foundation sobre a divulgação, os identificadores das falhas começaram a circular em 20/10. Depois, um vídeo de demonstração foi publicado por engano por uma das empresas pesquisadoras. A divulgação das correções foi antecipada em um dia.
Esse relato trata da circulação de informações sobre as vulnerabilidades e de uma demonstração de exploração. Ele não comprova que o código privado da sua empresa foi roubado. Se houver evidência de cópia de arquivos ou exposição de credenciais, existe uma segunda frente de trabalho: responder a um vazamento de código-fonte.
Como saber se o site da empresa usa PHP
Comece pela pessoa ou empresa que administra a hospedagem. Peça uma relação dos sistemas que executam PHP e a versão em uso em cada um. Inclua o site institucional, a loja e os sistemas internos publicados na internet.
A orientação conjunta da ENISA e de outras autoridades europeias recomenda identificar aplicações PHP, coordenar a atualização com os fornecedores e priorizar sistemas expostos à internet. Ela também alerta que produtos podem usar PHP internamente sem que isso seja evidente para o cliente.
Uma página com aparência moderna não revela a tecnologia do servidor. A ausência de .php no endereço também não resolve a dúvida. Evite encerrar a verificação com base no visual do site ou em uma ferramenta externa que apenas tenta reconhecer tecnologias.
Para organizar a cobrança, use uma linha por ambiente:
- Sistema e endereço: qual aplicação está sendo verificada.
- Responsável: quem tem acesso para corrigir o servidor.
- Versão e pacote: qual PHP atende às requisições do site.
- Correção: qual atualização foi aplicada e a referência do fornecedor.
- Validação: quem conferiu a versão ativa e os fluxos da aplicação.
Exemplo hipotético: uma empresa tem três aplicações, um site institucional, uma loja e um portal antigo de fornecedores. A hospedagem atualiza a loja, mas o portal fica em outro servidor. Uma resposta genérica de que “a conta foi atualizada” deixa uma das verificações em aberto.
Se o site usa WordPress
O comunicado oficial do WordPress informa que a versão do PHP pode ser consultada em Ferramentas > Saúde do site > Informações > Servidor. O painel da hospedagem também pode mostrar essa informação.
O mesmo comunicado esclarece que a correção deste caso pertence ao PHP. Atualizar apenas o WordPress, um tema ou um plugin não substitui a atualização do ambiente que executa o site. A manutenção desses componentes continua necessária, mas resolve outra camada do sistema.
Não publique uma página de diagnóstico com dados completos do servidor para pedir ajuda. Encaminhe somente as informações necessárias pelo canal privado de suporte.
Quais versões corrigem as falhas do PHP2Shell
Os avisos de segurança registram as seguintes versões corrigidas nos respectivos ramos:
- PHP 8.2.35.
- PHP 8.3.36.
- PHP 8.4.27.
- PHP 8.5.12.
A lista não é uma instrução para trocar qualquer instalação diretamente pela versão 8.5. A equipe precisa escolher um ramo suportado e compatível com a aplicação. Versões posteriores também devem ser avaliadas conforme os avisos de manutenção.
Há uma particularidade em servidores mantidos por distribuições Linux ou fornecedores de suporte estendido: a correção pode ser incorporada ao pacote sem seguir o mesmo número da distribuição original do PHP. Nesse caso, peça o boletim que confirma a correção das duas CVEs e a identificação do pacote instalado. Uma versão aparentemente antiga, isoladamente, não encerra a análise.
O anúncio do projeto PHP orienta usuários de PHP 8.1 e anteriores a consultar o fornecedor sobre correções ou migrar para uma versão suportada. Esses ramos não recebem manutenção regular do projeto. Para este caso, a equipe disponibilizou correções excepcionais em código-fonte para PHP 7.4, 8.0 e 8.1. Elas exigem avaliação técnica para aplicação e não restabelecem o suporte regular.
O que cobrar da hospedagem antes de considerar resolvido
Uma confirmação útil precisa dizer o que mudou no seu ambiente. Esta mensagem pode abrir o chamado:
Preciso confirmar a correção das CVEs 2026-109618 e 2026-109619 nos ambientes que atendem nossos sites. Informem a versão e a revisão do pacote PHP em execução, o boletim de correção aplicável e quando a atualização foi ativada. Se algum ambiente continuar pendente, indiquem a contenção adotada, o responsável e o prazo de correção.
Depois, peça a validação dos fluxos que sustentam o negócio. Em uma loja, por exemplo, abrir a página inicial não verifica o fechamento de pedido. A conferência precisa cobrir login, envio de formulário e pagamento conforme as integrações existentes.
Pergunte também se o processo que atende o site passou a executar o pacote corrigido. A versão exibida no terminal pode pertencer a outra instalação. Em ambientes com múltiplos servidores ou contêineres, a confirmação precisa abranger as instâncias ativas, e não apenas uma máquina de referência.
O registro final pode ser curto: ambiente, atualização aplicada, horário de ativação e resultado da validação. Guarde-o junto do chamado. Isso permite distinguir uma mudança concluída de uma promessa de atualização.
Firewall e backup ajudam, mas cada um resolve um problema
O projeto PHP informa que não há mitigação completa que substitua a atualização. Regras de firewall de aplicação, o WAF, podem integrar a proteção temporária, mas não devem ser tratadas como prova de que o interpretador foi corrigido.
Backup serve para recuperação. Ele não impede que um servidor vulnerável seja explorado. Antes da mudança, confirme que existem cópias dos arquivos e dos dados que podem ser restauradas, com acesso restrito. Se já houver suspeita de invasão, preserve as evidências antes de substituir o ambiente e não considere qualquer cópia recente automaticamente confiável.
O risco de voltar um backup também precisa entrar na decisão: pedidos recebidos depois da cópia podem deixar de aparecer no sistema restaurado. Por isso, o teste de recuperação e a conciliação dos dados fazem parte da operação. O guia sobre backup em nuvem para pequenas empresas aprofunda essa preparação.
Se a correção imediata não for viável, a orientação da ENISA é considerar o isolamento das aplicações expostas até que possam ser corrigidas. A decisão precisa envolver quem administra o ambiente e quem responde pelo negócio, com um canal alternativo para o atendimento quando necessário.
Atualizei o PHP. Como saber se houve invasão antes?
Aplicar o patch corrige a vulnerabilidade, mas não desfaz ações que um invasor eventualmente tenha executado. Se aparecerem contas desconhecidas, arquivos alterados sem entrega correspondente ou atividade suspeita nas integrações, encaminhe esses indícios para investigação. Eles não identificam sozinhos a causa do incidente.
Peça ao responsável técnico que preserve os registros relevantes e monte uma linha do tempo. O CERT.br orienta incluir logs ou outras evidências, com data, horário e fuso nas notificações de incidentes. Restrinja o acesso a esse material, pois ele também pode conter informação sensível.
A AWS relatou tentativas de exploração em seus sensores desde 17/10, antes da divulgação pública, e recomenda investigar desde pelo menos essa data. Nos ambientes que ficaram vulneráveis e expostos, peça essa janela inicial de análise, ampliando o período conforme a exposição e os registros disponíveis. A observação nos sensores não comprova invasão na sua empresa.
Sem evidência suficiente, registre o limite da análise. “Não encontramos indícios nos registros disponíveis” é diferente de garantir que nada aconteceu. Um ambiente sem logs não oferece a mesma capacidade de investigação de outro com registros preservados.
O que resolver hoje e o que entra na manutenção
Hoje, a tarefa é obter a confirmação por ambiente, corrigir o que está exposto e registrar a validação. Se ninguém consegue dizer quem administra o PHP, identifique esse responsável antes de encerrar o chamado.
Depois da urgência, combine quem acompanha alertas, quem autoriza atualizações e como a empresa recebe evidência de conclusão. Essas atividades precisam constar no escopo de manutenção. Veja o que considerar no custo de manter um sistema após a entrega para levar essa discussão ao fornecedor.
Se o seu levantamento parou em “não sabemos onde roda PHP”, leve a lista de sistemas e os chamados da hospedagem para uma avaliação de consultoria de TI. O primeiro resultado necessário é identificar os ambientes e seus responsáveis para conseguir cobrar a correção certa.