Em 21 de outubro de 2026, o projeto PHP publicou a correção de duas falhas críticas que permitem a alguém de fora, sem senha, assumir o servidor de um site. O PHP é a linguagem usada em cerca de sete de cada dez sites cuja tecnologia pode ser identificada. As falhas, apelidadas de PHP2Shell, existiam no código desde 2012, foram descobertas em agosto por pesquisadores que trabalharam com inteligência artificial (IA) e levaram governos europeus a desligar sites oficiais. Se você tem um site em WordPress ou em outro sistema feito em PHP, o PHP do servidor precisa ter a correção, o que, na maioria dos casos, significa estar em uma das versões corrigidas. Atualizar o WordPress não resolve.
O que é o PHP e por que a falha atinge tanto site
Todo site fica guardado em um servidor, um computador conectado à internet o tempo todo. Quando um visitante digita o endereço, esse computador prepara a página e a entrega ao navegador. Na maior parte dos sites, a linguagem que faz esse preparo é o PHP. Segundo a W3Techs, empresa que mede as tecnologias usadas pelos sites, 69,2% dos sites cuja linguagem de servidor é identificável usam PHP. O WordPress, o Drupal e o Joomla, três dos sistemas mais usados para criar sites, são escritos nele.
O número de 70% que circulou nas manchetes mede quantos sites usam PHP, e não quantos estavam vulneráveis. Ainda não há contagem confiável de sites expostos. O que torna o caso diferente é outro dado: a falha mora na linguagem, e não no que cada empresa programou em cima dela. A Wiz, companhia de cibersegurança responsável pela pesquisa, afirma que mesmo a página mais simples, rodando em uma versão afetada, pode ser atacada. Uma página em PHP pode ter só isto:
<?php
echo "Olá, mundo";São duas linhas, sem formulário, sem login e sem banco de dados. Se o PHP instalado no servidor for de uma versão afetada, até ela está exposta, porque o ataque não depende do que a página faz, e sim do programa que a executa.
Como uma página pessoal virou a base de boa parte da internet
O PHP nasceu pequeno. Em 1994, o programador dinamarquês-canadense Rasmus Lerdorf escreveu um conjunto de programas para cuidar da própria página pessoal na internet e o chamou de Personal Home Page Tools, ferramentas de página pessoal, que é de onde vem a sigla. Em junho de 1995, ele abriu o código para qualquer pessoa usar e modificar, e o PHP é gratuito e aberto desde então.
Em 1997, dois programadores de Tel Aviv, Andi Gutmans e Zeev Suraski, reescreveram a base do projeto. A versão 3, de junho de 1998, foi a primeira com o nome atual: a sigla passou a significar “PHP: Hypertext Preprocessor”, um processador de páginas da internet. Em 2000, o PHP 4 trouxe um motor novo, batizado de Zend com as primeiras letras dos nomes dos dois, e em 2004 saiu o PHP 5.
Entre uma versão e outra, o PHP ganhou o projeto que mais o espalhou. Em 2003, Matt Mullenweg e Mike Little criaram o WordPress a partir de um sistema de blog anterior, o b2/cafelog. O WordPress é escrito em PHP, também é gratuito e de código aberto, e deixou de ser só ferramenta de blog para virar a forma mais comum de montar um site: segundo a W3Techs, ele roda hoje em 39,6% de todos os sites do mundo e em 58,3% dos sites que usam um sistema de gerenciamento de conteúdo, o programa em que se escrevem e publicam as páginas sem mexer em código. Sozinho, o WordPress já põe o PHP em quase quatro de cada dez sites.
A linguagem continuou mudando. O PHP 7, de 2015, chegou a ser até duas vezes mais rápido que a versão anterior, e o PHP 8, de 2020, foi outra grande atualização. Os sites, porém, não acompanham as versões no mesmo ritmo. Pela W3Techs, 65,5% dos sites em PHP usam a versão 8, 26,7% ainda usam a 7 e 7,7% continuam na 5, lançada em 2004. Ou seja, mais de um terço dos sites em PHP roda em versões que o projeto já não atualiza.
A estrutura que mantém a linguagem continua enxuta. A PHP Foundation, criada por dez empresas que dependem do PHP, paga uma equipe de desenvolvedores, parte deles em tempo parcial, para cuidar da manutenção, da segurança e das novidades do PHP. É uma estrutura pequena para uma linguagem que sustenta boa parte da internet, e esse descompasso aparece de novo mais adiante, quando o conserto de 2024 travou.
O que a falha permite
As duas falhas foram registradas no catálogo público de vulnerabilidades como CVE-2026-109618 e CVE-2026-109619 e receberam 9,2, numa escala de gravidade que vai até 10. Essa nota leva em conta, entre outras coisas, de onde o ataque pode partir e o que ele exige. Nos dois casos, a ficha oficial registra que o ataque pode ser feito pela internet, sem login e sem que ninguém precise clicar em nada.
Os especialistas chamam esse efeito de execução remota de código. Um atacante, sem conta e sem senha, faz o servidor executar os comandos que ele quiser. Executar comandos no servidor equivale a ter acesso ao computador onde o site está: dá para ler o que está guardado nele, alterar arquivos e instalar programas. A agência de inteligência americana NSA alertou que brechas assim costumam abrir acesso aos arquivos e ao banco de dados do servidor, onde estão as informações de clientes e visitantes.
Como a falha funciona, sem jargão
Um servidor recebe uma solicitação para cada página aberta e reaproveita o mesmo programa para atender uma solicitação depois da outra. Para preparar cada página, o programa usa uma área de trabalho temporária, a memória, que deveria ser esvaziada ao fim de cada atendimento. O problema aparece quando a memória reservada para uma solicitação se esgota no meio do processamento: o PHP abandona o trabalho de forma abrupta e não limpa tudo o que estava usando.
O ataque explora essa sujeira em duas etapas. Na primeira solicitação, o atacante força o esgotamento da memória. Na segunda, atendida pelo mesmo programa, o PHP aproveita as sobras da anterior como se pertencessem à nova. A comparação mais próxima é a de um balcão que não foi limpo entre dois clientes, em que o atendente toma o papel esquecido pelo primeiro como instrução do segundo. Combinando essas etapas, os pesquisadores primeiro leram informações guardadas no servidor e depois o colocaram para executar comandos escolhidos por eles.
Os testes publicados mostram o ataque funcionando na forma mais comum de instalar o PHP junto com o servidor Apache (o chamado mod_php). Em outra forma muito usada (o PHP-FPM), a análise do código indica que o risco existe, mas ninguém havia demonstrado o ataque completo até a publicação. Quem administra o seu servidor sabe qual das duas ele usa.
Escondida desde 2012
Segundo a Wiz, todas as versões do PHP lançadas na última década são afetadas por pelo menos uma das duas falhas, a partir da versão 5.4, de 2012. Um integrante da equipe do PHP chegou perto do problema em 2024: ao corrigir outro defeito apontado por uma auditoria da empresa francesa Quarkslab, ele notou os primeiros indícios da falha de memória. O trabalho de correção, no entanto, foi interrompido e retomado diversas vezes durante meses.
Em seu comunicado, a PHP Foundation, organização que mantém a linguagem, reconheceu o erro sem rodeios:
“Não vamos fingir o contrário: o atraso foi uma falha estrutural, causada tanto pelo processo de decisão da equipe de segurança quanto pela falta de recursos.”
PHP Foundation, comunicado de 21 de outubro de 2026 (tradução nossa)
A equipe que cuida da segurança de uma linguagem usada por boa parte da internet é, nas palavras da própria fundação, um pequeno grupo de desenvolvedores pagos pela fundação, com um pouco de ajuda voluntária. A fundação anunciou mudanças: decisões por maioria, liderança com poder para destravar casos parados e uma equipe nova dedicada à segurança do ecossistema.
| Data | O que aconteceu |
|---|---|
| 2012 | Sai o PHP 5.4, a versão mais antiga afetada |
| 2024 | Um desenvolvedor do PHP nota os primeiros indícios do defeito de memória; o conserto trava |
| 1º/08/2026 | A Calif identifica uma das falhas com apoio do GPT-5.6 Sol |
| 19/08/2026 | A Wiz chega ao problema de forma independente |
| 20 e 21/08/2026 | A Wiz confirma o ataque contra o Drupal e contra o WordPress, em ambiente de teste |
| 24/08/2026 | A Wiz comunica a equipe de segurança do PHP |
| 17/10/2026 | A Amazon registra uma tentativa de ataque, quatro dias antes do anúncio |
| 20/10/2026 | Os identificadores das falhas vazam antes da data combinada |
| 21/10/2026 | O projeto PHP publica as versões corrigidas; governos tiram sites do ar |
Como a IA entrou na história
Duas equipes, sem contato entre si, encontraram o problema em agosto, e ambas trabalharam com IA. A primeira foi a Calif, empresa californiana que testa a segurança de sistemas simulando ataques. Ela identificou uma das falhas em 1º de agosto com o modelo GPT-5.6 Sol, dentro de um programa da OpenAI de busca de defeitos em software usado por todos. Dezoito dias depois, a Wiz, empresa do Google, encontrou o problema com o Gemini 4 Argon, do Google, o modelo da OpenAI e uma ferramenta de IA desenvolvida internamente.
A Wiz descreve com precisão onde a IA ajudou. Montar o ataque exigiu combinar vários defeitos e adaptá-lo à maneira particular com que cada versão do PHP distribui a memória, em rodadas sucessivas de tentativa, erro e ajuste. Os modelos de IA participaram dessas rodadas: examinaram as tentativas fracassadas e sugeriram correções. Segundo a empresa, um único pesquisador concluiu em uma semana o que antes tomaria meses de trabalho de uma equipe de primeira linha.
Isso não significa que a máquina encontrou a falha sozinha. Em todos os relatos, há pesquisadores decidindo o que investigar e validando cada passo. Neste caso, segundo a Wiz, o que mudou foi o custo: o trabalho que exigia uma equipe especializada por meses coube na semana de uma pessoa experiente com bons modelos. Vimos um padrão parecido em outra área no caso do ArtCraft, os programas que imitam a Adobe escritos com agentes de IA.
O sigilo vazou antes da correção
Falhas graves costumam ficar em sigilo até a correção estar pronta, com data combinada entre quem encontrou e quem mantém o software. O nome desse acordo é divulgação coordenada, e a lógica é simples: se a falha fica conhecida antes da correção, quem ataca sai na frente de quem precisa se defender. Por isso, distribuições de Linux e fornecedores de hospedagem recebem a correção com antecedência, para que tudo seja atualizado ao mesmo tempo. Desta vez, o sigilo não se sustentou. A Amazon informou ter registrado uma tentativa de ataque em 17 de outubro, quatro dias antes do anúncio, e disse não saber como o atacante obteve a informação. Na véspera da data marcada, os identificadores oficiais das falhas vazaram, com uma nota de gravidade errada, e um vídeo da Calif demonstrando o ataque foi publicado por engano. Na manhã de 21 de outubro, uma empresa de software liberou o pacote com a correção antes do horário acertado, o que permitiu a qualquer pessoa confrontar as duas versões do código e localizar o defeito.
No dia da correção, a Amazon relatou tentativas de ataque em larga escala, sem saber quantas tiveram sucesso. A Cloudflare, empresa que fica entre o visitante e o servidor de muitos sites para filtrar ataques, ativou um bloqueio automático contra o PHP2Shell para todos os seus clientes cerca de nove horas antes do anúncio. Esse tipo de bloqueio funciona como um filtro na porta: reconhece solicitações com o formato do ataque e as barra antes que cheguem ao servidor. Ajuda a ganhar tempo, mas não corrige o PHP, e só protege sites que passam pela Cloudflare.
Governos tiraram sites do ar; no Brasil, o governo federal emitiu alerta
Assim que a correção saiu, vários governos optaram por desligar sites por precaução até concluir a atualização: França, Alemanha, Bélgica, Países Baixos, Finlândia e República Tcheca. No caso holandês, o DigiD, sistema de login do cidadão nos serviços públicos, ficou indisponível. Em Paris, o site da Prefeitura de Polícia ficou inacessível. Nos Estados Unidos, a NSA recomendou atualizar sem demora; na União Europeia, o centro de resposta a incidentes das instituições do bloco, a CERT-EU, orientou a deixar o site fora do ar até poder aplicar a correção.
No Brasil, o CTIR Gov, centro que coordena a resposta a incidentes no governo federal, publicou o Alerta 93/2026 no dia 21, pedindo que os órgãos identificassem os sistemas em PHP e aplicassem as atualizações imediatamente, com base em um decreto que obriga a corrigir vulnerabilidades com urgência. Em reportagem sobre a falha publicada no mesmo dia, o Tecnoblog informou que serviços da Anatel ficaram inacessíveis e que o SEI, sistema eletrônico de processos usado por órgãos públicos, estava fora do ar.
O que fazer se você tem um site
A falha está no PHP do servidor, e por isso a ação depende de onde o seu site está hospedado. O caminho abaixo segue as orientações do projeto PHP, do WordPress e dos órgãos de segurança.
1. Descubra em que versão o PHP do seu site está
No painel do WordPress, abra Ferramentas e depois Diagnóstico; na aba Informações, a seção Servidor mostra a versão. As versões corrigidas são 8.5.12, 8.4.27, 8.3.36 e 8.2.35, ou mais novas. Para ler o número, olhe as duas primeiras partes para saber a linha (8.3, por exemplo) e a última para saber a atualização dentro dela: um site em 8.3.30 está na mesma linha da 8.3.36, mas ainda sem a correção.
Quem tem acesso ao servidor pela linha de comando pode digitar:
php -vA primeira linha da resposta traz a versão, no formato “PHP 8.3.36 (cli)”. Um cuidado: em alguns servidores, o PHP da linha de comando não é o mesmo que atende o site. Na dúvida, vale o que o Diagnóstico do WordPress ou a hospedagem informam.
Há ainda um terceiro caminho, sem login nenhum. Muitos servidores informam a versão do PHP na resposta que enviam ao navegador, num cabeçalho chamado x-powered-by. Foi assim que conferimos este blog, que roda em WordPress, em 26 de outubro:
x-powered-by: PHP/8.3.36É uma das versões que corrigem as duas falhas principais. Nem todo servidor mostra esse cabeçalho, e é comum escondê-lo de propósito, justamente para não facilitar a vida de quem procura versões vulneráveis.
2. Veja quem é responsável pela atualização
- Em hospedagem compartilhada, a atualização cabe à empresa de hospedagem. Hospedagem compartilhada é o plano comum, em que o seu site divide o servidor com sites de outros clientes. Confirme com a empresa que a correção foi de fato aplicada em todos os seus sites, e não apenas programada. Algumas empresas aplicaram a correção sem mudar o número da versão; nesse caso, vale o que a hospedagem confirmar.
- Em servidor próprio ou alugado só para você (VPS), a atualização é responsabilidade sua ou da sua equipe técnica. As medidas paliativas publicadas pelo projeto PHP reduzem o risco, mas o próprio projeto afirma que atualizar é a única correção completa.
3. Se a versão for antiga
As versões 8.1 e anteriores não terão versão oficial pronta para instalar. O projeto publicou apenas o trecho de código corrigido para as versões 7.4, 8.0 e 8.1. Quem está nelas depende da hospedagem ou de um fornecedor que mantenha versões antigas, e o caminho mais seguro é migrar para uma versão que ainda recebe correções.
O que não resolve e o que não significa
- Uma nova versão do WordPress ou dos plugins não corrige a falha. O WordPress informou que nenhuma atualização dele é necessária para este problema.
- Site fora do ar por algumas horas não significa site invadido. Muitas hospedagens e órgãos desligaram serviços por precaução enquanto atualizavam.
A terceira falha, de 23 de outubro
Dois dias depois da correção, o projeto PHP divulgou uma terceira falha relacionada, a CVE-2026-115560, que só ocorre numa combinação rara de configuração e código. A correção virá na próxima versão regular, e o CTIR Gov, na Recomendação 21/2026, classificou a probabilidade de exploração como baixa. Até lá, a medida indicada é desligar uma opção no arquivo de configuração do PHP, o php.ini, e reiniciar o serviço:
; php.ini
session.upload_progress.enabled = 0A mudança precisa ser feita na configuração do servidor; colocá-la no código do site não funciona. Se você não administra o servidor, repasse a informação a quem administra.
O que muda com a IA na segurança
O caso mostra os dois lados da mesma ferramenta, e quem disse isso primeiro foi a própria OpenAI, ao anunciar a correção:
“O caso mostra como a IA pode revelar falhas de segurança com impacto na escala da internet, mas as mesmas capacidades também podem ajudar atacantes a desenvolver rapidamente ferramentas ofensivas e formas de exploração.”
OpenAI, citada pela Fortune em 21 de outubro de 2026 (tradução nossa)
A PHP Foundation, por sua vez, contou que o volume de relatos de vulnerabilidade cresceu bastante com a popularização da pesquisa feita com IA. A partir de julho, a equipe publicou 15 correções de segurança e analisou mais de 100 relatos que se mostraram inválidos, repetidos ou impossíveis de reproduzir, cada um conferido por alguém da equipe.
Procurar brechas ficou mais barato para todos. Consertá-las continua dependendo de pessoas, e, no caso do PHP, de um grupo pequeno delas. No PHP2Shell, a primeira tentativa de ataque registrada veio quatro dias antes do anúncio. Na nossa leitura, quem já sabe onde o próprio site roda e quem o mantém é quem responde primeiro quando isso se repetir.
Nossa leitura
Para o visitante, um site invadido ou fora do ar é uma experiência ruim, venha de onde vier. Ele não sabe que o problema estava no PHP. Ele vê a página que não abre, o aviso do navegador ou, no pior caso, o próprio dado exposto.
Mesmo assim, o mercado ainda trata site como peça entregue: a empresa contrata, a página vai ao ar e ninguém mais olha o servidor. Na semana passada, governos com equipe e centro de resposta preferiram desligar serviços por precaução. Um site hospedado em servidor sem dono definido, ou preso a uma versão do PHP que deixou de receber atualizações, fica à espera de que alguém note o problema.
A pergunta que vale fazer hoje é simples: qual versão do PHP está por trás do seu site, e quem responde pela atualização dela? Se a resposta não vier fácil, é por ela que começamos.
Glossário
- Servidor: o computador, ligado à internet o tempo todo, onde o site fica guardado e onde as páginas são montadas.
- PHP: a linguagem de programação que monta as páginas de cerca de sete em cada dez sites, entre eles todos os feitos em WordPress.
- CVE: o código de registro de uma falha no catálogo público de vulnerabilidades, usado para que todos falem da mesma falha.
- Execução remota de código: quando alguém de fora consegue fazer o servidor rodar comandos escolhidos por ele, sem ter acesso legítimo.
- Divulgação coordenada: o acordo para manter uma falha em segredo até a correção estar pronta e publicá-la numa data combinada.
- Firewall de aplicação (WAF): o filtro que fica entre o visitante e o servidor e barra solicitações com formato de ataque conhecido.
- Hospedagem compartilhada: o plano em que vários sites de clientes diferentes dividem o mesmo servidor, mantido pela empresa de hospedagem.
Fontes
- Projeto PHP: anúncio das versões corrigidas (php.net, 21/10/2026), aviso da terceira falha (23/10/2026) e avisos de segurança GHSA-w8hw-w9fx-j79w e GHSA-6wmf-4rv5-p3rp no GitHub
- PHP Foundation: “Today’s PHP security release and how we’re strengthening PHP security” (21/10/2026)
- Wiz Research: “PHP2Shell: AI uncovers critical RCE vulnerabilities” (21/10/2026)
- Amazon Threat Intelligence: tentativa de ataque registrada antes da divulgação (21/10/2026)
- Cloudflare: proteção de firewall contra as falhas do PHP (21/10/2026)
- CTIR Gov: Alerta 93/2026 e Recomendação 21/2026
- WordPress Brasil: “Atualização crítica de segurança do PHP” (21/10/2026)
- Fortune, Al Jazeera, Times Brasil (CNBC/AFP), Canaltech, Tecnoblog e Malwarebytes, coberturas de 21 e 22/10/2026
- Manual do PHP: “History of PHP” (php.net)
- WordPress.org: “About” e “History”
- W3Techs: uso do PHP e do WordPress, consultado em 26/10/2026
- The PHP Foundation (thephp.foundation)
