Falha crítica no PHP (PHP2Shell): riscos e o que fazer

O que aconteceu com o PHP?

Em 21 de outubro de 2026, a equipe do PHP publicou atualizações de emergência para duas vulnerabilidades de execução remota de código (RCE) sem autenticação, ambas com nota 9,2 no CVSS v4.0. Elas ficaram escondidas no código da linguagem por mais de uma década e foram encontradas por pesquisadores das empresas Calif e Wiz com a ajuda de um modelo de inteligência artificial da OpenAI. A Wiz classificou o caso como as vulnerabilidades mais graves já descobertas por IA.

A repercussão foi imediata. Por precaução, o governo da Finlândia suspendeu serviços online, a agência de cibersegurança dos Países Baixos desconectou o próprio site, e a prefeitura de Edimburgo, a Wikipédia e a própria BBC tiraram páginas do ar. Nos Estados Unidos, a CISA pediu correção imediata e orientou desligar os sistemas que não puderem ser atualizados. Estimativas citadas na imprensa falam em cerca de 70% da web usando PHP, número que a BBC disse não ter conseguido verificar. Mesmo assim, o alcance é enorme.

Por que a falha é tão grave?

Porque o problema está no motor da linguagem, não no código do seu site. Um sistema bem escrito, com o código da aplicação limpo e auditado, continua vulnerável se roda sobre uma versão do PHP sem correção. Segundo a análise técnica da Sansec, as duas falhas são do tipo use-after-free, em que o PHP reaproveita uma área de memória já liberada:

• CVE-2026-109618: falha no tratamento do upload progress das sessões. Ela é acionada antes de qualquer linha do seu código rodar e pode vazar trechos da memória do servidor, como senhas, tokens de sessão, chaves de API e até chaves privadas TLS, além de permitir execução de código;
• CVE-2026-109619: falha no registro de erros fatais (backtrace), combinada com uma confusão de tipos no OPcache, que também leva à execução remota de código;
• Sem login e sem interação: basta uma requisição HTTP maliciosa ao servidor. Na prática, quem explora a falha pode instalar malwares e backdoors, roubar dados e usar o servidor para atacar terceiros.

Código bem feito não salva um servidor desatualizado. Neste caso, a brecha está embaixo da aplicação, no próprio PHP.

A Cloudflare registrou as primeiras tentativas de ataque às 07h43 (UTC) de 21 de outubro, horas antes de a correção ser publicada. Pesquisadores avaliam que a exploração em massa é mais difícil do que parecia no início, porque os exploits públicos ainda dependem de condições específicas. Mas criminosos costumam aperfeiçoar esses exploits em poucos dias. Contar com isso para não atualizar é uma aposta arriscada.

Quem é afetado?

Qualquer servidor que atende requisições web com PHP 5.4 ou superior ainda sem a correção, o que inclui as configurações mais comuns (Apache com mod_php e PHP-FPM). Como o PHP é a base de plataformas como WordPress, Drupal, Joomla, Magento, WooCommerce e de boa parte dos painéis de hospedagem, a lista vai muito além de "sites feitos em PHP":

• Sites institucionais e blogs em CMS ou em código próprio;
• Lojas virtuais, em que o vazamento de memória pode expor dados de clientes e de pagamento;
• Sistemas internos e ERPs web que muitas vezes ninguém lembra que estão expostos na internet;
• Hospedagens compartilhadas, em que a versão do PHP depende do provedor e às vezes fica presa numa versão antiga escolhida no painel anos atrás;
• Projetos legados em PHP 8.1 ou anterior, versões sem suporte que não recebem a correção oficial, só patches de código-fonte e pacotes de algumas distribuições.

Se vazarem dados pessoais de clientes, o problema deixa de ser só técnico. Entram as obrigações e sanções da LGPD, como comunicar o incidente à ANPD e aos titulares quando houver risco relevante.

Como corrigir agora (passo a passo)

A correção definitiva é uma só: atualizar o PHP. Esta é a ordem que recomendamos para sair do risco com segurança e sem derrubar o site:

1. Faça o inventário: liste todos os sites, sistemas e servidores com PHP, inclusive os esquecidos, como ambientes de teste, subdomínios antigos e painéis. A versão aparece no painel da hospedagem ou com o comando php -v;
2. Atualize para a versão corrigida da sua linha: 8.2.35, 8.3.36, 8.4.27 ou 8.5.12. Em hospedagem gerenciada, cobre do provedor a aplicação do patch e a confirmação por escrito;
3. Saia das versões sem suporte: quem roda PHP 8.1 ou anterior precisa migrar para uma versão suportada. Antes disso, faça backup e teste a compatibilidade da aplicação. Um backport da distribuição serve só como ponte temporária;
4. Reinicie o PHP-FPM ou o Apache depois da atualização. Sem isso, os processos antigos continuam rodando o código vulnerável;
5. Confirme a correção: confira a versão ativa e, em servidores Linux, verifique no changelog do pacote se os dois CVEs constam como corrigidos;
6. Mitigue enquanto não atualiza: um WAF (firewall de aplicação) e a diretiva session.upload_progress.enabled = 0 reduzem a superfície de ataque, mas não bloqueiam todas as variantes. Se não houver como atualizar logo, a orientação da CISA é tirar o sistema do ar até corrigir.

Atualizei. Meu site já está seguro?

Não necessariamente. A atualização fecha a porta, mas não expulsa quem já entrou. Como houve tentativas de ataque antes do patch, quem ficou exposto deve verificar sinais de comprometimento. A CISA recomenda monitorar processos do PHP que abrem shells ou baixam ferramentas. Também vale olhar arquivos modificados recentemente, usuários administrativos novos e consumo anormal de memória nos workers. Se encontrar algo estranho, siga o roteiro de o que fazer quando o site é hackeado e troque as senhas e chaves de API que estavam na memória do servidor.

Para ter certeza de que a brecha foi fechada e de que não sobrou outra porta aberta, o caminho mais seguro é um teste de intrusão (pentest) depois da correção.

Por que prevenção e acompanhamento são essenciais

O PHP2Shell mostra uma realidade que vale para qualquer tecnologia: falhas graves aparecem sem aviso, e a janela entre a divulgação e o primeiro ataque já é de horas. Desta vez, os ataques começaram antes mesmo da correção. Com a IA acelerando tanto a descoberta quanto a exploração de vulnerabilidades, o site que só recebe atenção quando quebra fica sempre um passo atrás. O próprio NCSC britânico recomendou, depois da correção, acompanhar continuamente as atualizações de segurança dos fornecedores.

• Atualizações em dia: PHP, CMS, plugins e dependências na versão suportada, com janela de manutenção planejada e não improvisada às pressas;
• Monitoramento de vulnerabilidades: alguém acompanhando os alertas (CVE, CISA, fornecedores) e avaliando o impacto no seu ambiente no mesmo dia;
• WAF e hardening: uma camada que filtra ataques conhecidos e ganha tempo quando surge uma falha nova;
• Backups testados fora do servidor principal, com restauração já ensaiada;
• Plano de resposta a incidentes: saber quem faz o quê na hora do problema reduz o tempo fora do ar e o prejuízo.

Esses itens formam a base de uma boa manutenção preventiva de site. Ela custa uma fração do que custa recuperar um site invadido, com os dados de clientes expostos e o Google exibindo alerta de site perigoso.

Como a VITALVES pode ajudar

A VITALVES desenvolve e mantém sistemas em PHP desde 2014 e atua com cibersegurança baseada no OWASP. Para quem foi pego de surpresa pelo PHP2Shell, oferecemos:

• Diagnóstico de exposição: inventário dos seus sites e servidores, versão do PHP em uso e nível de risco real;
• Correção e atualização segura: atualização do PHP, migração de versões sem suporte (8.1 ou anterior) com testes de compatibilidade e reinício controlado dos serviços;
• Verificação de comprometimento: análise de logs, arquivos e processos para confirmar que ninguém entrou antes do patch e, se entrou, contenção e limpeza;
• Manutenção e monitoramento contínuos: acompanhamento de vulnerabilidades, atualizações planejadas, WAF, backups e resposta rápida ao próximo alerta.

Não sabe qual versão do PHP o seu site usa ou se a hospedagem já aplicou a correção? Fale com a VITALVES. Fazemos o diagnóstico sem custo e dizemos com clareza o que precisa ser feito.

Fontes

• CISA — Critical Vulnerabilities in PHP Require Immediate Patching (21/10/2026);
• Sansec — PHP2Shell: Critical PHP RCE (CVE-2026-109618, CVE-2026-109619);
• BBC News Brasil — reportagem sobre as falhas no PHP e os sites retirados do ar.