PHP2Shell: falha crítica no PHP põe servidores e governos em alerta, e só a atualização resolve

PHP2Shell é o apelido de duas falhas graves descobertas no próprio PHP, a linguagem que roda por trás da maior parte dos sites do mundo, inclusive dos feitos em WordPress. As correções saíram em 21 de outubro de 2026, depois de um vazamento que antecipou o calendário, e governos de vários países, o brasileiro entre eles, tiraram sistemas do ar por precaução. Até 23 de outubro, nenhum órgão oficial confirmou um ataque bem-sucedido: as tentativas relatadas vêm de empresas privadas de segurança. Este artigo explica o que é a falha, quem está exposto e o que cada um precisa fazer.

Em resumo

O que é o PHP e por que isso importa

O PHP é uma linguagem de programação que roda no servidor, a máquina que entrega as páginas de um site. Quando alguém abre um blog em WordPress, uma loja virtual ou o sistema de um órgão público feito nessa linguagem, é o PHP que monta a página antes de ela chegar ao navegador. Segundo a W3Techs, que mede a tecnologia dos sites, o PHP aparece em 69,3% dos sites cuja linguagem de servidor é conhecida, em medição de 23 de outubro de 2026.

Por isso uma falha no próprio PHP é diferente de uma falha num plugin ou num tema. O problema não está no código do site, e sim no motor que executa esse código. WordPress, Drupal e Joomla ficam expostos pelo mesmo caminho. A Wiz, uma das empresas que descobriram as falhas, diz ter confirmado o ataque contra Drupal e WordPress ainda em agosto, durante a pesquisa.

As duas falhas, em linguagem comum

As duas falhas foram registradas pelo próprio PHP Group em 21 de outubro, com avisos publicados no repositório oficial do projeto no GitHub.

A primeira, CVE-2026-109618, acontece quando o PHP fica sem memória no meio de uma requisição. Nesse momento, algumas estruturas internas ficam montadas pela metade, e a rotina de limpeza que vem depois confia nelas como se estivessem completas. Um atacante que provoque esse estado de propósito pode chegar a executar código no servidor.

A segunda, CVE-2026-109619, é do tipo que os especialistas chamam de *use-after-free*: o programa continua usando um pedaço de memória que já tinha devolvido. Um dos caminhos demonstrados passa pelo recurso que mostra o progresso de envio de arquivos numa sessão, usado em formulários de upload.

As duas recebem nota 9,2 na versão 4.0 do CVSS, a escala internacional de gravidade que vai de 0 a 10. O registro oficial descreve um ataque feito pela rede, sem login e sem nenhuma ação da vítima. A ressalva técnica é que a complexidade é alta: o ataque exige condições específicas e não é trivial de montar.

O risco maior, segundo os avisos oficiais, está nos servidores Apache com o módulo mod_php, em que o ataque foi demonstrado antes mesmo de qualquer código do site rodar. No PHP-FPM, outra forma comum de rodar a linguagem, a primeira falha não teve exploração completa demonstrada, e a segunda foi validada pelo caminho do upload de sessão.

Por que “executar código” é o pior cenário

Nem toda falha de segurança tem o mesmo peso. Algumas deixam o atacante ler um arquivo, outras derrubam o site por alguns minutos. A execução remota de código, que é o caso das duas falhas do PHP2Shell, permite a quem está de fora dar ordens ao servidor como se fosse o dono dele. Daí vem o apelido: o ataque transforma o PHP numa porta de entrada para o terminal da máquina, o *shell*, na linguagem dos programadores.

Na prática, um servidor tomado assim pode ter os dados copiados, receber programas maliciosos, ser usado para atacar outros sistemas ou servir páginas falsas aos visitantes. É por isso que a avaliação da CISA anexada ao registro oficial classifica o impacto técnico como total, mesmo sem nenhum ataque confirmado até agora.

Fatos confirmados

Como a falha veio a público

A descoberta envolveu dois grupos. A Calif, pelo pesquisador Ryan Austin, encontrou os primeiros problemas em 1º de agosto e avisou o PHP em 11 de agosto. A Wiz encontrou a falha em 19 de agosto e reportou em 24 de agosto, com uma equipe formada por Sagi Tzadik, Shir Tamari, Nir Ohfeld e Tomer Schwartz. Os avisos no GitHub também dão crédito a pesquisadores identificados como da OpenAI.

A divulgação não saiu como planejado. Segundo a PHP Foundation e a cronologia publicada pelo desenvolvedor Ben Scherzer, os números das falhas circularam em 20 de outubro, por volta das 15h UTC, e o lançamento foi antecipado de 22 para 21 de outubro. A Calif publicou e depois apagou um vídeo de prova de conceito, e a Chainguard, empresa que distribui software, publicou versões corrigidas antes do horário combinado com o projeto.

A inteligência artificial teve papel na história. A Wiz diz ter usado os modelos Gemini 4 Argon e GPT-5.6 Sol, além de uma ferramenta própria, para encontrar as falhas, e a PHP Foundation conta ter usado ferramentas de IA na triagem dos relatos. A Calif afirma que a causa de fundo é antiga: um erro de falta de memória reportado em 2020 e outro visto numa auditoria de 2024 não foram corrigidos na época, por falta de prova de que pudessem ser explorados.

Um projeto gigante mantido por poucos

O PHP é software livre, de código aberto, e tem na PHP Foundation uma das organizações que bancam o seu desenvolvimento. Em texto publicado no dia das correções, a fundação informou ter publicado 15 falhas com registro CVE desde 1º de julho de 2026 e pediu patrocínio a empresas, hospedagens e governos que dependem da linguagem. Na leitura do Tectônica, o pedido deixa à mostra um descompasso: uma peça presente na maioria dos sites com linguagem conhecida depende de uma estrutura enxuta para revisar, corrigir e coordenar avisos como este.

O que dizem os órgãos oficiais

Do lado das empresas de infraestrutura, Dane Knecht, diretor de tecnologia da Cloudflare, disse ao BleepingComputer que as regras de firewall da empresa são temporárias e não dispensam a atualização. Gina Peter Banyard, desenvolvedora do PHP, afirmou ao mesmo veículo que nenhuma mitigação bloqueia totalmente os ataques.

Alegações de exploração, ainda sem confirmação oficial

As notícias de ataques em andamento vêm de empresas privadas, e nenhuma delas foi verificada de forma independente até 23 de outubro.

A própria watchTowr diz que ninguém teve sucesso até agora, mas Jake Knott, da empresa, avisou à SecurityWeek que não espera que esse quadro dure muito.

Quantos servidores estão expostos

Ninguém sabe ao certo, e as estimativas variam demais para servir de número único. A Mallory, usando o buscador de dispositivos Shodan, contou 2,24 milhões de servidores que anunciam usar PHP, dos quais 59% dos que mostram a versão estariam em ramos sem correção oficial. O VirusTotal fala em 5,1 milhões, a Infrawatch em 11 milhões de serviços, e a Palo Alto Networks em mais de 22,6 milhões de instâncias, sem divulgar o método. A Infrawatch ressalva que estar visível não significa estar vulnerável.

O alerta no Brasil

O efeito mais visível no país foi a retirada preventiva de sistemas. O Ministério da Gestão e da Inovação orientou “retirar temporariamente do ar todos os sistemas desenvolvidos em PHP” e informou que o SEI, o sistema eletrônico de processos usado por órgãos federais, saiu do ar, enquanto o GOV.BR continuou funcionando normalmente.

Segundo o Canaltech, a Anatel tirou seu SEI do ar e esclareceu que o caso “não se trata de uma falha ou vulnerabilidade inerente ao SEI”. O TRF1 e a Justiça Federal da 4ª Região cortaram o acesso externo a sistemas, e o TRF6 suspendeu prazos. Não há confirmação de invasão em nenhum desses casos.

O CTIR Gov publicou o Alerta 93/2026 às 15h29 de 21 de outubro. Já o CERT.br, centro que trata incidentes na internet brasileira, não tinha alerta publicado sobre o caso até a consulta deste artigo.

Fora do país, Holanda, Finlândia, Áustria, Alemanha, França e Bélgica também tiraram sites do ar, entre eles o DigiD, sistema de identidade digital holandês, segundo a Gazeta do Povo.

Onde as fontes divergem

Uma falha mais antiga costuma aparecer no mesmo noticiário e não deve ser confundida com esta. A CVE-2024-4577, que atinge o PHP-CGI no Windows, é de junho de 2024 e está no catálogo de falhas exploradas da CISA desde 12 de junho daquele ano.

O que fazer

Quem administra servidor. Atualize para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 e reinicie todos os processos do PHP, porque a versão nova só vale depois do reinício. Confira a versão que o servidor web usa de fato, que pode ser diferente da que aparece no terminal. A watchTowr lembra que distribuições Linux às vezes corrigem a falha sem mudar o número da versão.

Se não der para atualizar já, o projeto PHP lista medidas parciais: definir `memory_limit=-1` na configuração do administrador, baixar o `post_max_size` para 8M, ou 32M se o site recebe uploads, e desligar o progresso de upload com `session.upload_progress.enabled=0`. No PHP 8.5 também ajuda `fatal_error_backtraces=0`. Esconder as mensagens de erro não protege. Quem está no 8.1 ou em versão anterior precisa pedir a correção ao fornecedor, migrar para uma versão suportada ou isolar o servidor da internet, como recomenda a CISA.

Para investigar invasão, a Amazon e a Huntress sugerem olhar a partir de 17 de outubro: processos do PHP abrindo terminais ou baixando ferramentas, arquivos novos na pasta do site, tarefas agendadas e contas criadas sem explicação. Logs limpos não provam que o servidor está seguro. Firewall de aplicação ajuda por pouco tempo, mas não substitui a atualização.

Quem tem site em hospedagem compartilhada. É o caso da maioria dos blogs em WordPress. Pergunte à hospedagem se a correção já está instalada, e não apenas agendada. A Malwarebytes lembra um ponto que confunde muita gente: atualizar o WordPress ou os plugins não atualiza o PHP, que é responsabilidade de quem cuida do servidor. No painel da hospedagem, costuma ser possível ver a versão do PHP em uso e compará-la com a tabela de versões corrigidas.

Quem só visita sites. Desconfie de redirecionamentos estranhos, downloads que começam sozinhos e pedidos de login inesperados. E um site fora do ar nesta semana não significa site invadido: muitos foram desligados de propósito, por precaução, enquanto recebiam a atualização.

O quadro de outubro

O PHP2Shell é real, grave e já corrigido. O que ainda não existe é confirmação oficial de que alguém tenha conseguido explorar a falha: até 23 de outubro de 2026, os relatos de ataque vêm de empresas privadas, e as falhas seguem fora do catálogo de exploração ativa da CISA. A recomendação de todos os órgãos consultados é a mesma: atualizar o PHP agora, antes que essa situação mude.

Fontes: 1 · 2 · 3 · 4 · 5 · 6 · 7 · 8 · 9 · 10 · 11 · 12 · 13 · 14 · 15 · 16 · 17 · 18 · 19 · 20 · 21 · 22 · 23 · 24 · 25 · 26 · 27 · 28 · 29