PHP2Shell: a corrida contra o tempo – o que as falhas do PHP significam para sites, dispositivos e seus dados

Duas falhas críticas no PHP, um embargo quebrado antes da hora e tentativas de ataque ainda antes da divulgação oficial: o PHP2Shell não afeta apenas sites tradicionais. O runtime vulnerável também pode estar incorporado a firewalls, painéis de hospedagem e outros dispositivos. Explicamos de forma clara o que aconteceu, quem precisa agir e o que você realmente deve fazer como usuário comum.

Em 20 de outubro, dois números inicialmente discretos apareceram na internet: CVE-2026-109618 e CVE-2026-109619. Por trás deles estavam duas vulnerabilidades no PHP que ainda não haviam sido divulgadas por completo. PHP é a tecnologia que processa formulários, consulta bancos de dados e gera páginas em inúmeros servidores web.

A divulgação deveria seguir uma sequência organizada: primeiro as atualizações e as regras de proteção preparadas, depois os detalhes técnicos. Mas os identificadores se tornaram públicos antes da hora, uma pontuação máxima incorreta de 10,0 começou a circular e, naquela noite, um vídeo mostrando um ataque funcional foi publicado por engano. O PHP antecipou o lançamento em um dia.

Tarde demais para um início tranquilo: mais tarde, a Amazon encontrou uma tentativa de exploração datada de 17 de outubro, quatro dias antes do patch. Após a divulgação, provedores registraram uma onda de ataques em rápido crescimento; a Reuters, citando a Cloudflare, relatou milhões de tentativas em poucas horas. Isso não significa milhões de invasões bem-sucedidas, mas mostra a velocidade com que vulnerabilidades críticas são hoje testadas de forma automatizada.

A falha em si não está no seu smartphone. Ainda assim, ela pode afetar você por meio de dados armazenados por um provedor, sites manipulados, phishing mais convincente ou serviços retirados do ar por precaução. Seu dispositivo pode estar limpo enquanto seus dados correm risco em um servidor de terceiros.

O que você precisa saber primeiro

PHP2Shell é o nome dado a duas falhas de segurança de memória no núcleo do PHP. Em determinadas condições, invasores podem executar código em um servidor sem fazer login; uma das vulnerabilidades também pode expor conteúdos da memória contendo tokens de sessão, senhas, chaves de API ou credenciais de banco de dados. As duas CVEs receberam nota 9,2 no CVSS 4.0.

As ramificações upstream estão corrigidas a partir do PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Ramificações mais antigas podem receber correções retroportadas por distribuições, provedores de hospedagem ou fornecedores LTS. Atualizar apenas o CMS ou um plugin não é suficiente: o que importa é o runtime do PHP que realmente processa as requisições web.

Usuários comuns não precisam instalar nada no celular. Os operadores devem inventariar e corrigir sites, contêineres, interfaces de administração e dispositivos que utilizam PHP, além de investigar possíveis ataques anteriores.

1. Como um antigo problema de memória virou uma corrida global contra o tempo

2024: um sinal de alerta sem ataque comprovado

A história começou em 2024. Durante uma auditoria externa de segurança do PHP, surgiram os primeiros indícios do que mais tarde se tornaria o problema de falta de memória. No entanto, ainda não havia um caminho confiável entre uma requisição web e a execução de código, e possíveis correções ameaçavam afetar a compatibilidade ou a estabilidade. A pequena equipe de segurança não chegou rapidamente a um consenso. Mais tarde, a PHP Foundation descreveu abertamente o atraso como uma falha estrutural: os processos de decisão eram lentos demais e os recursos, escassos demais.

Verão de 2026: pesquisa assistida por IA transforma teoria em prática

Em julho e agosto de 2026, Calif, OpenAI e Wiz examinaram o núcleo do PHP com métodos tradicionais e modelos avançados de IA. Em 11 de agosto, foi relatado um caminho concreto para Remote Code Execution; de forma independente, a Wiz encontrou outras variantes e demonstrou cadeias de ataque contra aplicações PHP reais. Ainda era necessário que pessoas reproduzissem os resultados, eliminassem falsos positivos e analisassem os patches. Mesmo assim, a IA encurtou a busca – e, com ela, o tempo que os defensores têm após a divulgação de uma falha.

17 de outubro: a primeira tentativa conhecida

A Amazon Threat Intelligence identificou posteriormente, na telemetria do MadPot, uma tentativa de exploração datada de 17 de outubro. Uma detecção em honeypot não comprova que sistemas reais tenham sido comprometidos com sucesso, mas faz a janela de investigação forense retroceder. Não se sabe como o agente obteve informações suficientes tão cedo; não há uma atribuição confiável.

20 e 21 de outubro: o embargo é rompido e o patch é lançado

Em 20 de outubro, os identificadores CVE começaram a circular publicamente, junto com a pontuação CVSS incorreta de 10,0 e um vídeo de ataque publicado por engano. O PHP antecipou o lançamento para 21 de outubro, às 14h00 UTC. Provedores de hospedagem, distribuições e empresas de segurança prepararam pacotes e filtros em paralelo. A Cloudflare ativou regras de proteção antes mesmo do lançamento, combinando sinais de requisições e respostas. Ainda assim, um WAF é apenas uma barreira adicional: ele não corrige o código PHP vulnerável.

As versões corrigidas foram lançadas em 21 de outubro; pouco depois surgiram ferramentas públicas de exploração e varreduras em massa. Órgãos públicos, hospitais, universidades e empresas retiraram serviços do ar por precaução, incluindo temporariamente serviços policiais em Berlim e Brandemburgo. Isso não comprova uma invasão; pode, ao contrário, demonstrar que o processo de emergência funcionou: é melhor ficar offline de forma controlada do que permanecer comprometido sem controle. O PHP2Shell também deixa claro que sistemas expostos à internet precisam reagir a falhas críticas de RCE em horas, não em dias.

Estão confirmadas duas vulnerabilidades críticas no PHP, tentativas ativas de exploração e uma superfície potencial de ataque muito ampla. Ainda não se sabe quantos sistemas foram realmente comprometidos nem quantos dados foram perdidos.

2. O que dá errado tecnicamente – sem jargão desnecessário

O PHP trabalha na sala de máquinas de um site: executa o código de WordPress, lojas virtuais ou portais, processa entradas e se comunica com bancos de dados. As falhas ficam abaixo da camada do CMS. Por isso, uma aplicação totalmente atualizada ainda pode estar usando um runtime PHP vulnerável.

CVE-2026-109618: limpeza com dados incompletos

Se o PHP atingir seu memory_limit no momento errado, o processamento pode ser interrompido enquanto estruturas de dados internas ainda estão apenas parcialmente inicializadas. Durante a limpeza, o PHP pode tratar essas áreas como dados válidos. Um invasor tenta provocar deliberadamente esse estado e influenciar a organização da memória para chegar à execução de código.

Foi demonstrado um ataque não autenticado no Apache com mod_php que pode agir antes da execução do próprio código da aplicação. Nesse caso, login, autenticação de dois fatores ou um plugin de segurança do WordPress não oferecem proteção. Outros modos de execução do PHP também podem ser afetados; os pré-requisitos e a confiabilidade variam conforme a SAPI, a aplicação e a configuração.

CVE-2026-109619: uma referência obsoleta sobrevive à requisição seguinte

Na segunda falha, uma referência a uma área de memória já liberada permanece após um erro grave. Quando o mesmo worker do PHP processa uma requisição posterior, ele volta a acessar esse estado obsoleto – um use-after-free, ou estado global desatualizado.

As consequências podem incluir execução de código, travamentos ou exposição de conteúdo da memória. Esta última é especialmente traiçoeira: um invasor não precisa deixar uma web shell visível para obter tokens de sessão, senhas de banco de dados, chaves de API ou certificados. Portanto, depois de aplicar o patch, não basta procurar apenas arquivos alterados.

Remote Code Execution significa, inicialmente, executar código com os privilégios da conta do PHP ou do servidor web, e não obter acesso root automaticamente. Essa conta pode, porém, ler configurações, alcançar bancos de dados ou acessar serviços internos. Permissões de arquivos, segmentação de rede e privilégio mínimo determinam até onde um comprometimento pode avançar.

3. Quase 70% da internet está realmente afetada?

Em 23 de outubro de 2026, a W3Techs informou que o PHP era usado por 69,3% dos sites cuja linguagem de programação no lado do servidor o serviço consegue identificar. Entre esses sites PHP, 65,3% utilizavam PHP 8, 26,9% PHP 7 e 7,7% PHP 5.

Esses números descrevem a adoção, não o estado dos patches nem ataques bem-sucedidos. Muitos sistemas foram atualizados em poucas horas, distribuições fornecem backports com números de versão mais antigos e, em dispositivos, o caminho vulnerável pode não estar acessível publicamente. Portanto, a conclusão justa é: cerca de sete em cada dez sites com linguagem no lado do servidor identificável usam PHP e precisaram revisar suas defesas. Não é possível estimar com seriedade quantos continuam vulneráveis ou comprometidos hoje.

4. O que o PHP2Shell significa para você como usuário comum

O PHP não infecta diretamente seu dispositivo

O PHP2Shell é executado em servidores. Você não precisa restaurar seu smartphone nem instalar um aplicativo especial. O risco para seu dispositivo só surge se um site manipulado induzir você a baixar algo malicioso. Mantenha o sistema, o navegador e os aplicativos atualizados e use somente fontes confiáveis. Uma suposta “atualização do PHP2Shell” para o seu dispositivo provavelmente é uma isca.

Seus dados ainda podem ser afetados

Ao fazer uma compra em uma loja virtual, seu nome, endereço e histórico de pedidos podem permanecer armazenados por muito tempo. Se o servidor for comprometido, esses dados podem ser afetados mesmo que você não visite o site há meses. A exposição da memória também pode revelar tokens e chaves de acesso que não existem como arquivos no servidor.

Até mesmo um site conhecido pode ser manipulado: o domínio e o ícone de cadeado permanecem iguais enquanto um script injetado rouba dados de login ou pagamento. O HTTPS protege o caminho até o servidor, não a integridade do servidor. Interrompa a operação diante de janelas de pagamento incomuns, redirecionamentos ou downloads inesperados e entre em contato com o fornecedor por um canal conhecido.

Depois do ataque técnico, muitas vezes vem a fraude

Detalhes roubados tornam o phishing mais convincente. Até uma mensagem com seu nome verdadeiro e o número correto do pedido pode ser falsa. Abra serviços importantes pelo aplicativo oficial, por um favorito ou digitando você mesmo o endereço. Sinais de tomada de conta incluem alertas inesperados de login ou redefinição de senha, sessões desconhecidas, dados de recuperação alterados e solicitações push, TAN ou de autenticação de dois fatores que você não iniciou. Não aprove nada “por segurança”; verifique diretamente a conta e remova dispositivos desconhecidos.

No internet banking, uma senha ou um PIN geralmente não bastam por causa da autenticação forte do cliente. Ainda assim, o phishing pode induzir você a aprovar uma autorização legítima para o login ou pagamento de outra pessoa. Verifique o destinatário, o IBAN e o valor; em caso de transações desconhecidas, contate o banco pelo aplicativo oficial ou por um número já conhecido.

O que você pode fazer agora

Se um serviço informar apenas manutenção ou uma interrupção preventiva, você não precisa trocar senhas indiscriminadamente nem bloquear cartões. Use um canal alternativo oficial e acompanhe as comunicações do fornecedor.

Se um fornecedor informar uma possível exposição de credenciais de acesso, altere a senha nesse serviço e em todos os outros nos quais você a reutilizou. Encerre sessões ativas, habilite autenticação de dois fatores ou passkeys e dê atenção especial à segurança da sua conta de e-mail.

Se você inseriu dados em um site suspeito ou instalou um suposto aplicativo de segurança, proteja suas contas a partir de outro dispositivo, contate o banco se houver dados de pagamento envolvidos e mande verificar o dispositivo afetado.

Nenhum aplicativo de segurança e nenhuma VPN podem reparar o runtime PHP da loja virtual de terceiros. Um software de proteção pode ajudar contra a segunda onda de ataques com downloads maliciosos, aplicativos falsos e sites maliciosos conhecidos, mas não garante que os dados armazenados em um servidor externo estejam seguros.

5. O PHP também está presente em firewalls, sistemas NAS e outros dispositivos

O PHP não está apenas em sites, mas também em interfaces de administração e serviços adicionais de firewalls, roteadores, sistemas NAS, painéis de hospedagem, sistemas VoIP, gravadores de câmeras e appliances industriais. Um produto só é afetado se utilizar uma versão vulnerável do PHP para processar requisições web acessíveis. Também importam o nível de exposição e a disponibilidade de um patch do fabricante.

pfSense: a Netgate confirmou que a interface gráfica baseada em PHP e o captive portal são afetados. A interface padrão normalmente só pode ser acessada pela LAN; um captive portal atende intencionalmente clientes não confiáveis. Portanto, a mesma falha apresenta riscos diferentes conforme a exposição.

Palo Alto Networks: determinadas versões do PAN-OS e do Panorama são afetadas. Segundo o fabricante, o problema atinge a interface web de gerenciamento, incluindo a API XML, mas não de forma geral o plano de dados nem o GlobalProtect. Até que a correção seja instalada, o gerenciamento deve ser acessível apenas por redes confiáveis ou por um jump host controlado.

Plesk: os sites dos clientes usam seus próprios handlers PHP, enquanto a interface do Plesk utiliza um mecanismo separado. Atualizar apenas uma camada pode deixar a outra esquecida. Por isso, a Plesk publicou atualizações para os dois componentes.

Cisco e Sophos mostram por que produtos, serviços em nuvem e instalações dos clientes precisam ser avaliados separadamente. A Cisco confirmou que algumas famílias de produtos eram afetadas, classificou outras como não afetadas e ainda investigava produtos adicionais. A Sophos declarou que seus produtos não eram afetados, mas retirou temporariamente do ar o antigo portal MyUTM, hospedado separadamente, porque ele utilizava uma versão vulnerável do PHP.

O NCSC dos Países Baixos mantém uma lista de status atualizada continuamente. Ela é um inventário valioso, mas não substitui o aviso mais recente do fabricante: uma dependência do PHP, por si só, não comprova que a falha seja explorável, e a ausência de um comunicado não significa que não haja risco.

O que verificar em um dispositivo em casa ou na empresa

Anote o fabricante, o modelo, o firmware e os pacotes adicionais. Pesquise pelas duas CVEs e por “PHP2Shell” no site oficial de suporte e instale atualizações somente pelo mecanismo previsto de firmware ou pacotes. Nunca substitua por conta própria o PHP incorporado; appliances frequentemente contêm adaptações do fabricante e componentes assinados.

Desative o gerenciamento remoto pela WAN, encaminhamentos de porta e liberações UPnP desnecessários e revise os acessos remotos pela nuvem. Se precisar de acesso externo, use uma VPN sempre que possível e só então abra a interface local.

Separe as redes de convidados, IoT e gerenciamento para que dispositivos comprometidos não alcancem serviços administrativos locais. Se um firewall, NAS ou gravador de câmeras não recebe mais atualizações de segurança, a substituição muitas vezes é a única solução sustentável.

6. O que os operadores precisam fazer agora

Etapa 1: definir responsabilidades e inventariar os ativos

Na hospedagem gerenciada, o provedor geralmente realiza a atualização; em VPS, servidores dedicados, contêineres e appliances, a responsabilidade é sua ou do seu prestador de serviços. Exija uma resposta verificável sobre as duas CVEs, a versão do pacote ou firmware e a reinicialização de todos os processos PHP. Ao mesmo tempo, inventarie domínios, subdomínios, ambientes de staging, projetos antigos, webmail, contêineres e dispositivos com PHP incorporado.

Etapa 2: verificar o nível correto do patch

PHP 8.5.12 · PHP 8.4.27 · PHP 8.3.36 · PHP 8.2.35. Há backports do código-fonte disponíveis para PHP 7.4, 8.0 e 8.1; o aviso da distribuição ou do fornecedor LTS é a referência válida.

As distribuições podem retroportar correções para versões mais antigas de pacotes. O Ubuntu 24.04 LTS, por exemplo, lista 8.3.6-0ubuntu0.24.04.13 como corrigida; o cPanel também forneceu backports. Compare, portanto, a versão completa do pacote com o aviso da distribuição ou do fornecedor da plataforma, e não apenas com o número upstream isolado.

Etapa 3: verificar o runtime realmente ativo

php -v normalmente mostra apenas a versão da linha de comando. O servidor web pode usar outra instalação por meio de PHP-FPM, mod_php ou um contêiner. Verifique, portanto, pools FPM, módulos do servidor web, hosts virtuais e imagens:

php -v
php -r 'echo PHP_VERSION, " | ", PHP_SAPI, PHP_EOL;'
systemctl list-units --type=service 'php*-fpm.service'

Após a atualização, os workers antigos precisam ser substituídos: com mod_php, normalmente reiniciando o servidor web; com PHP-FPM, reiniciando os pools. Reiniciar um contêiner com a mesma imagem não resolve; a imagem precisa ser atualizada e implantada novamente.

Etapa 4: impedir que requisições cheguem ao PHP em sistemas que não podem ser corrigidos

Se não for possível aplicar o patch imediatamente, restrinja o acesso a redes confiáveis ou a uma VPN – ou retire o serviço do ar. Um plugin de manutenção do WordPress não protege se o ataque agir antes do código da aplicação. Use uma página de manutenção estática ou bloqueie o acesso no proxy reverso, balanceador de carga ou servidor web.

Regras de WAF e CDN podem ganhar tempo, mas não são um patch. A Cloudflare observou padrões de ataque em mudança e precisou avaliar requisições e respostas em conjunto. Certifique-se também de que o servidor de origem não possa ser acessado diretamente por um segundo endereço IP ou nome de host alternativo.

Medidas de configuração do PHP, como desativar o progresso de upload da sessão ou impor limites mais rígidos de memória e upload, reduzem apenas alguns caminhos de ataque e podem causar efeitos colaterais.

Etapa 5: investigar retroativamente pelo menos até 17 de outubro

Preserve logs de servidor web, PHP, proxy, WAF, sistema e contêiner antes que sejam sobrescritos pela rotação. Procure requisições de formulário incomuns, PHP_SESSION_UPLOAD_PROGRESS, erros de memória, processos shell inesperados, novos arquivos, contas, tarefas cron e conexões de saída. Um ataque bem-sucedido não precisa derrubar o worker; por outro lado, um único erro não comprova uma invasão. O conjunto das evidências é o que importa.

Etapa 6: rotacionar os segredos acessíveis ao PHP

Como conteúdos da memória podem ser expostos, em sistemas acessíveis pela internet que permaneceram sem patch você deve rotacionar todos os segredos que o processo PHP conseguia ler – como senhas de banco de dados, tokens de API, nuvem e implantação, credenciais SMTP ou OAuth e chaves de sessão. Primeiro corrija ou isole o sistema afetado; depois gere novas credenciais a partir de um ambiente confiável.

Etapa 7: diante de sinais de comprometimento, não apenas “limpar”

Se houver sinais de comprometimento, isole o sistema de forma controlada, preserve os logs e, quando apropriado, os dados voláteis, e reconstrua hosts críticos a partir de artefatos confiáveis em vez de apenas apagar arquivos visíveis. Revise também contas administrativas e de banco de dados, pipelines de implantação e sistemas conectados. Se dados pessoais puderem ter sido afetados, envolva desde cedo os responsáveis pela proteção de dados; segundo o GDPR, uma violação sujeita a notificação geralmente deve ser comunicada em até 72 horas.

7. A lição mais ampla: a descoberta acelera e a correção precisa acompanhar

O PHP2Shell mostra como a IA está deslocando a fronteira entre o que é “teoricamente possível” e o que é “explorável na prática”. Modelos podem analisar em grande escala código-fonte, rastros de falhas e diferenças entre patches; com isso, também diminui o intervalo entre a divulgação e o surgimento de código de exploração funcional.

A resposta não é simplesmente usar mais IA. Mantenedores precisam de recursos e processos de decisão claros; operadores precisam de inventários completos, ciclos rápidos de aplicação de patches, isolamento e recuperação praticada. Na Protectstar, usamos IA em conjunto com revisões de código e validação humana. Ela acelera a descoberta, mas não substitui a responsabilidade.

Conclusão

O PHP2Shell atinge servidores, mas pode chegar até você como risco aos dados, tentativa de fraude ou indisponibilidade de serviço. Fique atento, sem entrar em pânico: use canais oficiais de contato, não aprove solicitações inesperadas e reaja de forma direcionada aos comunicados dos fornecedores afetados.

Para os operadores, o que importa é o runtime PHP realmente ativo, cada instância esquecida, os componentes incorporados, a reinicialização de processos antigos e a análise retroativa até pelo menos 17 de outubro. Se não houver patch, o isolamento é mais responsável do que manter o serviço em operação. Um site acessível não é prova de que ele esteja seguro.