Nesta semana muita gente tentou abrir o site de um tribunal, de uma agência reguladora ou da prefeitura e deu de cara com a página fora do ar. O detalhe é que, na maioria dos casos, não foi hacker que derrubou. Foram as próprias equipes que desligaram os sites, de propósito, para não serem invadidas.
O motivo tem nome: PHP2Shell. Uma falha no PHP, a linguagem que roda por baixo de quase sete em cada dez sites do mundo, inclusive da maioria dos sites feitos em WordPress. Se você tem empresa com site, loja virtual, página de captura ou área de membros, essa história provavelmente também é sua.
Vou explicar sem tecniquês o que aconteceu, por que dessa vez foi diferente e, principalmente, o que você precisa perguntar hoje para quem cuida do seu site.
O que é a PHP2Shell
PHP2Shell é o apelido de duas falhas, a CVE-2026-109618 e a CVE-2026-109619, encontradas dentro do próprio PHP. Não é um plugin mal feito nem um tema pirata. É o motor que faz o site funcionar.
Juntas, as duas falhas permitem que alguém de fora, sem login e sem senha, execute comandos no servidor onde o site está hospedado. Na prática é como deixar a chave da loja pendurada na porta. A nota de gravidade é 9,2 de 10, e o código com problema estava no PHP há mais de dez anos: as versões afetadas começam no PHP 5.4, de 2012, e vão até as mais recentes.
Seis dias que tiraram sites do ar no mundo inteiro
A cronologia ajuda a entender o tamanho do susto. No dia 17 de outubro, a Amazon registrou nos servidores-isca que ela mantém para estudar ataques uma tentativa de explorar a falha. Quatro dias antes de qualquer anúncio oficial.
No dia 20, os detalhes vazaram no Hacker News, um fórum muito lido por programadores, e um vídeo mostrando o ataque funcionando foi publicado por engano por uma das empresas que tinham encontrado a falha. O PHP antecipou a correção para o dia seguinte.
No dia 21 saíram as versões corrigidas: 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Poucos minutos depois, a empresa de segurança watchTowr já via tentativas reais de ataque nos sensores dela. Foi aí que governos e empresas pelo mundo começaram a desligar sistemas.
Por que tanta gente preferiu tirar o site do ar
Na Holanda, saíram do ar o DigiD e o MijnOverheid, que são a porta de entrada dos cidadãos para os serviços do governo. Na França, sites do Ministério do Interior. Também houve sistemas desligados em órgãos da Finlândia, da Alemanha e da Bélgica. A BambooHR, sistema de RH usado por empresas dos Estados Unidos, do Canadá e da Irlanda, ficou fora do ar e interrompeu processos de folha de pagamento. Serviços de apoio da Wikimedia e o Internet Archive também tiveram períodos fora.
A orientação que justificou boa parte desses desligamentos veio da NSA, a agência de segurança dos Estados Unidos: se não dá para atualizar, tire o sistema do ar. A lógica é simples. Site fora do ar por dois dias é prejuízo. Site invadido pode virar vazamento de dados, golpe com o nome da sua empresa e meses de dor de cabeça.
O que aconteceu no Brasil
Aqui, o CTIR Gov, centro que coordena a resposta a incidentes de segurança no governo federal, emitiu um alerta no dia 21 pedindo que os órgãos identificassem os sistemas em PHP e atualizassem. Para quem não conseguisse, a recomendação foi "considerar a restrição temporária do acesso público às aplicações vulneráveis". Em português de empresário: tira do ar até corrigir.
O efeito mais visível foi no SEI, o sistema de processos eletrônicos usado por boa parte da administração pública, que ficou indisponível em vários órgãos. A Anatel explicou que "a indisponibilidade temporária do serviço está relacionada a uma vulnerabilidade recente identificada no próprio PHP". O TRF-1 suspendeu o acesso externo ao SEI em "caráter preventivo", o TRF-6 suspendeu o expediente e retomou no dia 22, e o TRF-4 também suspendeu serviços. Em Rondônia, saíram do ar sites do governo do estado, do Tribunal de Justiça e da prefeitura.
O Ministério da Gestão informou que os sites federais e o Gov.BR não foram afetados. E, até agora, não há confirmação de invasão no Brasil. A Sansec, empresa especializada em segurança de lojas virtuais, avaliou no dia 22 que um ataque em massa parece menos provável do que se temia no começo. Mas menos provável não é impossível, e ninguém quis pagar para ver. Uma empresa de segurança ouvida pelo jornal O Tempo falou em milhões de tentativas de invasão no mundo.
Por que dessa vez foi diferente: quem achou a falha foi a IA
Essa é a parte que mais me chamou a atenção. A PHP2Shell foi encontrada pela Wiz Research, pela Calif e pelo time de Codex Security da OpenAI, usando inteligência artificial. Segundo os próprios pesquisadores, um único pesquisador trabalhando com IA fez em cerca de uma semana o que levaria meses para um time inteiro.
Repare: o código com defeito estava ali havia mais de dez anos. Sinais do problema já tinham aparecido numa auditoria de 2024 e não foram corrigidos. A própria PHP Foundation chamou a demora de "uma falha estrutural".
Em setembro eu escrevi aqui sobre o GPT-6 Astra, o primeiro modelo que a própria OpenAI classificou como risco cibernético crítico, justamente porque ele encontra falhas que ninguém tinha encontrado. A PHP2Shell mostra os dois lados dessa moeda na mesma semana. A IA que acha a falha para corrigir é a mesma que acha a falha para atacar. E ela acha muito mais rápido do que qualquer equipe humana.
O seu site está nessa conta?
Segundo a W3Techs, que monitora as tecnologias usadas pelos sites do mundo, 69,3% dos sites com linguagem identificada rodam em PHP. Estão aí a maioria dos sites em WordPress, as lojas em WooCommerce, os portais em Joomla e Drupal. Os pesquisadores da Wiz demonstraram o ataque funcionando nas versões mais recentes de WordPress, Drupal e Joomla.
E tem um agravante. 34,7% dos sites em PHP ainda usam a versão 7 ou mais antiga. Para o PHP 7.4, 8.0 e 8.1 existe só um remendo no código-fonte, que alguém precisa aplicar na mão. Não existe versão oficial corrigida pronta para instalar. No PHP 5, não existe nada.
Quem precisa agir depende de onde o seu site está e de quem cuida dele:
Caso 1: hospedagem compartilhada ou gerenciada
Se você paga uma hospedagem e não mexe em servidor, quem corrige é ela. A Hostinger, por exemplo, informou que corrigiu todos os planos, menos os de VPS, até o dia 22. O cPanel e a CloudLinux, que estão por trás de muitas hospedagens, também liberaram versões corrigidas.
O detalhe que pega muita gente: o número da versão do PHP pode continuar o mesmo depois da correção. Por isso, o que vale conferir é a data de compilação, que precisa ser de 21/10/2026 ou depois. Peça à hospedagem a confirmação por escrito.
Caso 2: VPS ou servidor próprio
Aqui ninguém vai fazer por você. É preciso atualizar o PHP para uma das versões corrigidas e reiniciar o servidor hoje. Existem medidas paliativas, como desligar a opção de progresso de upload de sessão e apertar os limites de memória, mas elas só reduzem o risco. Um firewall como o da Cloudflare também ajuda, mas só se o seu servidor aceitar tráfego exclusivamente vindo da Cloudflare. Sem atualizar, nenhuma medida paliativa basta.
Caso 3: site feito por agência ou freelancer
Depende do contrato. E é aqui que mora o maior perigo, porque cada lado acha que o outro está cuidando. A agência acha que é a hospedagem, a hospedagem acha que é o cliente, e o cliente nem sabe que existe a pergunta. Descubra hoje quem é o responsável e peça a confirmação por escrito. Se ninguém assumir, o responsável é você.
Checklist para fazer hoje
- Descubra onde o seu site está hospedado e quem tem acesso a ele. Nome da hospedagem, tipo de plano e quem tem a senha. Se você não sabe responder isso em dois minutos, esse já é o primeiro problema.
- Veja a versão e a data do PHP. No WordPress, o caminho é Ferramentas, Saúde do site, Informações, Servidor. Para qualquer site, a hospedagem consegue informar.
- Peça confirmação por escrito de que o PHP foi corrigido, com a data de compilação de 21/10/2026 ou depois.
- Se o site ainda está no PHP 7 ou mais antigo, monte um plano de migração. Não é só por causa desta falha. O PHP 8.2 deixa de receber correções de segurança em 31 de dezembro de 2026, então quem está nele também precisa se programar.
- Fique de olho em sinais estranhos: erros 500 e falta de memória sem explicação, cookies de sessão gigantes nos registros e o servidor reiniciando sozinho. Se aparecer algo assim, chame quem administra o servidor na hora.
- Tenha um backup fora do servidor. Se o pior acontecer, é ele que coloca a empresa de pé de novo.
- Se não dá para corrigir agora, tire o site do ar e coloque uma página de manutenção até a correção. Foi o que fizeram governos e tribunais, e foi o que as autoridades de segurança recomendaram.
A lição que vai além do PHP
Eu converso com muito empresário, e a frase que mais escuto quando o assunto é site é "isso é com o pessoal de TI". Não é. O seu site é a sua loja. É onde o cliente compra, onde o lead se cadastra, onde o anúncio que você pagou vai parar. Saber quem cuida dele, onde ele está e o que acontece se ele cair é decisão de dono.
E tem uma pergunta que esta semana deixou escancarada: se o seu site sair do ar por dois dias, o seu negócio para? Se a resposta for sim, o problema não é só técnico. É de dependência. Eu falei disso quando escrevi sobre as buscas sem clique do Google: quem tem a própria audiência, com lista de e-mail, WhatsApp e redes, continua vendendo enquanto resolve o problema. Quem depende de um único canal fica parado esperando.
Por fim, olhe para o que vem pela frente. A IA vai encontrar falhas cada vez mais rápido, em sistemas cada vez mais antigos. A empresa que tem processo, responsável e plano de resposta trata isso como mais um dia de trabalho. A que não tem descobre pelo cliente reclamando no Instagram.
Imersão Sprint, 9 e 10 de novembro, em Alphaville. Se esta semana mostrou que partes importantes da sua operação estão no escuro, comece por elas. Dois dias redesenhando, na prática e com o seu notebook, um processo da sua empresa em volta da IA. Você não sai com anotação, sai com a máquina montada e rodando.
Enviar minha aplicaçãoFontes: o resumo técnico das falhas, as versões corrigidas, a cronologia e os desligamentos fora do Brasil conforme a Wikipedia, o The Hacker News e a Gazeta do Povo. Alerta do CTIR Gov, SEI, Anatel, tribunais federais e posição do Ministério da Gestão conforme O Tempo. Situação em Rondônia conforme o Rondônia Agora. Participação do PHP e das versões conforme a W3Techs, consultada em 23/10/2026. Orientações para sites em WordPress conforme a Patchstack. Correção nas hospedagens e data de compilação conforme a Hostinger. Avaliação sobre ataques em massa conforme a Sansec. Foto de capa: corredor de servidores no centro de supercomputação NERSC, nos Estados Unidos, por Derrick Coetzee (domínio público, CC0).
