PHP2Shell: falha crítica no PHP achada por IA e o que atualizar hoje

Se a sua empresa tem site, loja ou sistema interno em PHP, a primeira coisa a fazer hoje não é ler este texto. É mandar uma mensagem a quem opera o servidor com uma pergunta de uma linha: qual versão do PHP está rodando e quando ela foi atualizada. A resposta cai numa das linhas da tabela abaixo. Depois volte, porque o resto do caso explica por que essa pergunta ficou urgente numa quarta-feira de outubro, por que ela vai voltar, e quem deveria estar respondendo por ela.

Em um parágrafo, para quem não é de TI

O PHP é a linguagem de programação que roda no servidor de sete em cada dez sites do mundo com linguagem conhecida, segundo o W3Techs em 22 de outubro de 2026. Está por trás do WordPress, do Drupal, das lojas em Magento e WooCommerce e de muito sistema interno que uma empresa usa há anos. Em 21 de outubro, o projeto PHP publicou a correção para duas falhas. Elas permitem a um invasor executar comandos no servidor pela internet, sem senha. Uma delas, segundo a Wiz, também deixa ler trechos da memória do programa que está rodando, onde podem estar senhas e chaves de outros acessos. O conserto não está no site, no tema nem no plugin. Está no servidor, e é feito por quem opera o servidor.

O que atualizar, por versão, e quem costuma fazer

A release (a versão publicada) saiu às 11h de Brasília. Cada falha recebeu um número de registro público, o CVE, e a nota 9,2 numa escala que vai até 10, a CVSS v4.0. A orientação do aviso de segurança (advisory) é uma só: todo usuário de PHP deve atualizar imediatamente. Na tabela, "distribuição Linux" é o fornecedor do sistema do servidor, como Ubuntu e Debian, que empacota o PHP e distribui a correção.

Um detalhe de calendário para quem escolher o destino: o 8.2, a mais antiga das quatro versões que receberam release, chega ao fim da vida em 31 de dezembro de 2026. Subir para ela hoje é repetir esta conversa em dois meses.

Como saber se a sua empresa está exposta, sem ser técnico

Não é preciso abrir servidor nenhum. São quatro perguntas, e a quarta é a que importa.

1. Quais sites e sistemas a empresa tem no ar? Site institucional, loja, área do cliente, portal de parceiros, intranet, sistema de chamados, sistema que a agência fez há cinco anos. Lista em papel serve.
2. Quais deles rodam PHP? Site em WordPress, Joomla ou Drupal roda PHP. Loja em Magento, WooCommerce ou PrestaShop roda PHP. Sistema feito sob medida em Laravel ou em "PHP puro" roda PHP. Na dúvida, a pergunta a quem fez é "isso é PHP?", e a resposta é sim ou não.
3. Para cada um, qual versão e quando foi atualizada? A mensagem cabe em três linhas, e pode ser copiada:

Olá. Por causa da correção crítica do PHP de 21/10 (PHP2Shell), preciso saber qual versão do PHP serve o nosso site ou sistema, quando ela foi atualizada e, se ainda não foi, qual o prazo. As versões corrigidas são 8.5.12, 8.4.27, 8.3.36 e 8.2.35.

4. Quem respondeu, em quanto tempo? Se a resposta veio no mesmo dia, com versão e data, a empresa tem alguém cuidando daquele servidor. Se ninguém soube dizer, ou se a resposta foi "o site está no ar e funcionando", a empresa acabou de descobrir que aquele servidor não tem dono. Essa descoberta vale mais do que qualquer detalhe técnico deste caso.

Quem achou a falha, e por que isso muda o calendário

As duas falhas existem no PHP desde a versão 5.4, de 2012. Nenhuma das fontes consultadas registra ataque usando essas falhas antes de 2026, e a OpenAI diz que, até onde sabe, a IA chegou antes dos invasores.

Quem as encontrou foram duas equipes de segurança, em relatos independentes, trabalhando com modelos de inteligência artificial. A Wiz Research descobriu a primeira em 19 de agosto e relatou ao projeto PHP em 24 de agosto. A Calif, empresa de segurança que audita o PHP dentro do programa Patch the Planet, da OpenAI, tinha chegado antes: relatou em 11 de agosto uma falha de execução remota de comandos com a mesma causa. Segundo a OpenAI, ela foi achada com o GPT-5.6 Sol. Os modelos usados estão na linha do tempo, no fim do texto.

Do primeiro relato à correção foram 71 dias, pela nossa conta. O prazo não é lentidão. A PHP Foundation diz que publicou 15 CVEs desde 1º de julho e, no mesmo período, processou mais de 100 relatos que se mostraram inválidos, duplicados ou irreproduzíveis. Os modelos que acham falha também produzem relatos que alguém precisa descartar, e uma pessoa toma cada decisão.

O que muda para a empresa está em duas frases das próprias descobridoras. A Wiz escreve que os modelos de IA mais avançados, os de fronteira, "reduziram substancialmente essa barreira, transformando uma falha antiga em um exploit". Exploit é o código que explora a falha, e a Wiz acrescenta que a mesma ferramenta ajuda a adaptá-lo a versões e configurações diferentes. A OpenAI escreve que espera que "descobertas semelhantes aumentem muito nos próximos meses". Lidas juntas, as duas frases sugerem que a release de outubro não é a última do gênero. Quem trata atualização de servidor como evento raro vai receber mais avisos como este, e o custo de cada um é menor para quem já tem rotina e responsável.

Um terço dos sites PHP está fora do suporte oficial

O W3Techs, que mede a linguagem de servidor dos sites que consegue identificar, mostrava em 22 de outubro de 2026 o PHP em 69,3% dos sites com linguagem conhecida. Entre os sites PHP, 65,3% rodam a versão 8, 26,9% a 7, 7,7% a 5 e 0,1% a 4. A soma fecha em 100,0%.

Somando 7 e 5: 34,6% dos sites PHP rodam uma versão que não recebeu release do projeto. É um piso, porque parte dos 65,3% da versão 8 está em 8.0 e 8.1, que também ficaram sem release, e o W3Techs não separa esse pedaço. O número não descreve sites abandonados. Descreve sistemas que funcionam e que ninguém teve motivo para mexer. O backport em código-fonte que o PHP publicou para 7.4, 8.0 e 8.1 existe para esse público, e exige compilar, ou seja, gerar o programa a partir do código-fonte.

No nosso trabalho, o PHP que preocupa raramente é o do site novo. É o do sistema interno que "nunca precisou mexer", em versão antiga, em servidor sem fornecedor de distribuição por trás e, às vezes, sem ninguém na empresa com a senha do servidor. A conversa sobre quem atualiza o PHP é a mesma que aparece quando um cliente pergunta se a X-Apps pode assumir a hospedagem e a manutenção de um site que outra equipe construiu: antes do orçamento vem o inventário.

O que a manchete exagera, e o que ela acerta

A release estava marcada para 22 de outubro. Em 20 de outubro, por volta do meio-dia em Brasília (15h UTC), os identificadores das duas CVEs vazaram em fóruns e redes sociais, com uma nota CVSS de 10,0 que não era a real. O PHP publicou o pré-anúncio antes da hora e antecipou a release em um dia. No fim da tarde (20h UTC), a Calif publicou por engano um vídeo com sua prova de conceito, a demonstração de que o ataque funciona, e, segundo a Foundation, o desenvolvimento de exploits acelerou. Na madrugada seguinte, às 4h43 de Brasília (7h43 UTC), a Cloudflare relatou os primeiros ataques mirando as duas falhas, segundo a Sansec e o BleepingComputer. A proteção que ela ligou foi uma regra de firewall de borda, o filtro que fica na frente do servidor, e o próprio diretor de tecnologia a chamou de temporária. A agência de segurança nacional dos Estados Unidos e o centro de segurança cibernética do Reino Unido, segundo a imprensa, recomendaram tirar do ar o que não pudesse ser corrigido. É esse enredo que a TechCrunch chamou de "PHP Armageddon".

As fontes técnicas contam o mesmo dia com outro tom. A PHP Foundation escreve que sua equipe não tinha identificado nenhum exploit funcional no momento da release. A Sansec, que acompanha ataques a lojas virtuais, revisou sua análise em 22 de outubro para dizer que a exploração em massa ficou menos provável do que esperava. Os motivos: ninguém mostrou uma requisição única que funcione contra qualquer servidor vulnerável; as provas de conceito públicas não funcionam contra uma instalação padrão; e a maioria delas depende de um segundo defeito, de inclusão local de arquivo, na aplicação alvo. Em português corrente: as receitas de ataque publicadas até agora precisam de um segundo defeito no próprio site para funcionar. A watchTowr diz ter visto tentativas em seus servidores-isca (honeypots); nenhuma das fontes consultadas publicou uma invasão bem-sucedida confirmada.

Ataque observado quer dizer que alguém está mandando requisições. Não quer dizer que alguém entrou. A manchete acerta na urgência e erra no pânico: a decisão correta é a mesma nos dois cenários, atualizar, e o que muda é a ordem e o tom com que se faz isso. Uma ressalva nossa, para quem demorar. A primeira falha permite ler memória do programa em execução, segundo a Wiz. Nossa leitura é que um servidor que ficar dias sem correção, exposto à internet, deveria ter as senhas e chaves guardadas nele trocadas depois da atualização.

Para quem o alarme é menor, e para quem é maior

O alarme é menor para quem está numa distribuição Linux mantida ou numa hospedagem gerenciada (aquela em que o provedor administra o servidor) que já confirmou a correção. Um relato de administrador no Hacker News fala em pacote do Debian e em uma hospedagem gerenciada corrigindo cerca de uma hora depois da release; outras, segundo a Investing.com, não tinham confirmado prazo no dia 21. Também é menor para quem já roda 8.2 ou acima com atualização automática, com uma ressalva que o próprio Ubuntu escreve. A atualização automática (unattended-upgrades) aplica a correção em até 24 horas, mas não reinicia o Apache com mod_php, que é o PHP rodando dentro do servidor web Apache, configuração comum em servidor antigo. Sem reinício, o processo antigo continua no ar. Regra de firewall de borda, como a da Cloudflare, reduz a exposição enquanto o pacote não chega; a Cloudflare mesma a tratou como temporária.

O alarme é maior em quatro situações. Sistema interno exposto à internet em PHP 5 ou 7, sem distribuição por trás. Servidor com Apache e mod_php, o cenário em que a própria equipe do PHP demonstrou ataque sem depender de defeito da aplicação. Loja virtual em Magento, WooCommerce ou plataforma parecida, porque, como a Sansec aponta, o defeito está no PHP em si e não no código da loja. Segundo a mesma Sansec, a Calif relatou execução de código alcançável em Magento, WordPress, Drupal, Joomla, Laravel e WHMCS. E quem instala PHP pelo remirepo, um repositório de pacotes mantido por voluntário, que o advisory pediu para trocar pelo pacote da distribuição, porque não teria atualização no dia.

A declaração do WordPress, reproduzida pela imprensa, resume a parte que confunde: a falha não é do WordPress, e o plugin não a corrige. Quem corrige é quem opera o servidor.

Três contas, e só a primeira é pequena

Para uma empresa, este caso tem três contas.

A primeira é a atualização em si, para quem está numa das quatro versões com release. É uma tarefa de operação: aplicar o pacote, reiniciar os processos, conferir que o site voltou. Quem tem alguém cuidando do servidor resolve isso no dia, e o custo é o de uma rotina que já existe.

A segunda é a migração, para quem está em 7 ou em 8.0 e 8.1. Trocar o PHP 7 pelo 8 raramente é só trocar o programa instalado: o código quebra em pontos conhecidos, componentes mudam, e é preciso testar o sistema inteiro antes de virar a chave. Isso é engenharia, não operação, e o tamanho depende do sistema. Não há número honesto que valha para todos; o que vale é levantar quantos sistemas estão nessa situação, porque cada um deles é um projeto esperando um orçamento.

A terceira é a conta de não fazer. Um servidor com dados de clientes tomado por execução remota de código é candidato ao que a LGPD chama de incidente de segurança com risco relevante. O artigo 48 manda comunicar esse incidente à ANPD, a autoridade nacional de proteção de dados, e às pessoas donas dos dados, no prazo que a autoridade define. A avaliação é caso a caso, e nenhuma das fontes deste caso publicou invasão confirmada; mas a comparação entre uma tarde de operação e um comunicado de incidente é a que o decisor precisa ter na mesa.

Como o alerta foi tratado numa operação contínua: a UNICEF

A X-Apps é parceira técnica da UNICEF na execução contínua de serviços em Drupal, que roda em PHP: ambientes separados de desenvolvimento, homologação (o ambiente de teste que espelha a produção) e produção, publicação com rastreabilidade, monitoramento, relatórios e acordos de nível de serviço com evidências. O desenho está descrito no case da UNICEF. Em 21 de outubro, o dia em que a correção saiu, a operação atendeu este alerta no portal da UNICEF, que autorizou a menção ao caso.

Depois do alerta crítico, a equipe iniciou uma verificação extraordinária, com apoio do scanner externo de vulnerabilidades da Pentest-Tools.com, e confirmou que o ambiente precisava receber a correção. Como a operação já tinha responsáveis definidos e documentação técnica, o atendimento seguiu a rotina já documentada: verificar os componentes de que o sistema depende, preparar a atualização e testar os fluxos principais em homologação, incluindo o acesso administrativo, a publicação de conteúdo e as integrações.

Com os testes concluídos e um plano de reversão pronto, a atualização foi para produção no mesmo dia. Em seguida vieram três conferências que separam "atualizei" de "está corrigido": a versão que está de fato rodando nos serviços, as verificações funcionais repetidas no ambiente real, e os registros e indicadores do ambiente nas horas seguintes.

Ao final, a UNICEF recebeu um relatório com o que foi verificado, a correção aplicada, os testes realizados e as recomendações de acompanhamento. O que a operação contínua muda é a condução: há uma equipe responsável por avaliar o alerta, executar a mudança e comunicar o resultado, e a organização acompanha a resolução sem tirar a atenção das próprias atividades. É também por isso que a operação não depende da atualização automática do servidor, que, como visto acima, aplica o pacote mas não reinicia o serviço nem testa nada. É o contrário da quarta pergunta da seção de inventário: aqui o servidor tem dono, e o dono responde pelo alerta.

As três perguntas da empresa brasileira nesta semana

A primeira vai para a hospedagem. Qual versão do PHP serve o meu site, quando ela foi atualizada e, se for hospedagem compartilhada (vários sites no mesmo servidor do provedor), quem aplica a correção. Painéis que deixam escolher a versão do PHP por site resolvem metade do problema com um clique; a outra metade é confirmar que a versão escolhida é uma das quatro corrigidas. No dia 21, segundo a Investing.com, três grandes hospedagens gerenciadas ainda não tinham confirmado prazo; a pergunta por escrito é o que gera a resposta por escrito.

A segunda vai para a agência ou fornecedor que construiu o site ou a loja. Quem opera o servidor desde a entrega, e o contrato de manutenção cobre atualização do PHP ou só do tema e dos plugins. A resposta frequente, "o site está no ar e funcionando", não responde a pergunta.

A terceira vai para dentro da empresa. Quantos sistemas internos rodam PHP, em que versão, em que servidor, e quem tem acesso para atualizar. Para os que estão abaixo de 8.2, a decisão é entre o pacote da distribuição, se existir, o backport compilado, e a migração.

A decisão desta semana cabe numa planilha de quatro colunas: cada servidor PHP da empresa, a versão, quem aplica a atualização e a data em que ela foi aplicada. Linha sem nome na terceira coluna é o risco real deste caso, mais do que qualquer CVE. É isso que a X-Apps faz num contrato de operação DevOps: alguém com nome responde pelo servidor, a atualização de segurança vira rotina com registro, e a migração do sistema antigo entra na agenda com orçamento, em vez de esperar a próxima manchete.

Quantos servidores PHP a sua empresa tem, e para quantos deles você sabe dizer hoje quem aplica a atualização?

Para quem opera o servidor: a nota técnica

Quem está em risco, nas palavras do advisory: toda instalação que serve requisições web, o que inclui PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. O risco maior é no mod_php, onde a equipe demonstrou um ataque disparado por uma requisição sem autenticação antes de qualquer código da aplicação rodar. A CVE-2026-109618 é uma corrupção por falta de memória: quando uma requisição estoura o memory_limit no momento errado, o PHP abandona o processamento com dados internos pela metade, e a limpeza trata o dado inválido como válido. A CVE-2026-109619 é estado global obsoleto: um erro fatal deixa o estado de uma requisição apontando para memória já liberada, e a requisição seguinte, no mesmo worker, reaproveita esse estado. A Wiz agrupa quatro bugs de memória nas duas CVEs e diz que um programa que só imprime "hello world", em versão vulnerável, é explorável.

Para quem não consegue atualizar na hora, o projeto lista paliativos com uma ressalva escrita por ele mesmo: eles reduzem a exposição a caminhos específicos e não tornam a instalação segura. São eles: memory_limit=-1 definido de um jeito que a aplicação não consiga sobrescrever; post_max_size baixo, 8M sem upload de arquivo e 32M com; session.upload_progress.enabled=0 no php.ini ou no pool, nunca por ini_set() nem .user.ini, com reinício de todos os workers; e, no 8.5, fatal_error_backtraces=0. Depois do pacote, reinicie o Apache com mod_php ou o PHP-FPM, porque o processo antigo continua vulnerável até lá. Sinais de ataque que a Wiz lista: requisições multipart incomuns seguidas de erro de memory_limit, HTTP 500 repetidos, cookies PHPSESSID grandes ou malformados e reinícios inesperados de workers. Os advisories GHSA-w8hw-w9fx-j79w e GHSA-6wmf-4rv5-p3rp trazem o detalhe completo.

Perguntas frequentes

Linha do tempo, com a fonte de cada data

Os cálculos de dias (71) e de fatia sem release (34,6%) são nossos, sobre as datas e os percentuais acima. A observação sobre projetos da X-Apps é experiência própria, não medição. O atendimento da UNICEF aconteceu em 21 de outubro de 2026 e é relatado com autorização do cliente, sem detalhe do ambiente. Versões corrigidas e paliativos valem até a próxima release de segurança do PHP; relatos de ataque valem para 21 e 22 de outubro de 2026. Declarações da NSA e do WordPress chegaram pela TechCrunch; as da Cloudflare, pela Sansec e pelo BleepingComputer.

Leia também

• Credencial exposta e agente de IA: a porta já estava aberta
• Engenharia reversa com agente de IA: o que o REA faz e onde a lei para
• Pós-lançamento: rotina de correções e quem decide a próxima versão