IA derrubou sites? Entenda as falhas no PHP e o risco para quem navega

RESUMO ＋

O uso de inteligência artificial em pesquisas de segurança não comprova ataques comandados por IA. O problema está nos servidores que sustentam sites, não no navegador do visitante. Administradores e empresas de hospedagem precisam aplicar as correções. Proteções adicionais podem reduzir a exposição, sem substituir a atualização.

---

As falhas críticas no PHP que levaram serviços a suspender acessos nesta quarta-feira, 21, estão nos servidores que fazem os sites funcionar. Para quem navega, isso significa que a correção depende da empresa responsável pela página ou de sua hospedagem, não de uma atualização no próprio computador.

O alerta envolve duas vulnerabilidades, identificadas como CVE-2026-109618 e CVE-2026-109619, com gravidade 9,2 em uma escala de 10. Elas podem permitir a execução remota de código sem autenticação: em termos simples, um invasor poderia fazer o servidor executar instruções indevidas.

Segundo a OpenAI, a Calif encontrou uma das falhas com apoio do GPT-5.6 Sol; a Wiz identificou ambas de forma independente. É um exemplo do uso defensivo da tecnologia, tema da cooperação entre empresas de IA em cibersegurança.

Descobrir uma falha com IA não comprova um ataque feito por IA.

Por que a falha no PHP afeta sites, e não só programadores?

O PHP é uma linguagem usada nos bastidores da web. Quando alguém acessa uma página, o servidor executa o código e envia o resultado ao navegador. Esse trabalho pode incluir processar formulários e gerar conteúdo. O visitante não precisa instalar PHP para abrir o site.

O WordPress usa PHP, mas essa dependência não significa que todos os sites construídos com a plataforma foram invadidos. É necessário distinguir exposição a uma vulnerabilidade de comprometimento comprovado. Para o responsável pelo site, atualizar apenas temas e plugins também não equivale a corrigir o PHP da hospedagem.

A Cloudflare informou ter observado tentativas de exploração. Isso indica atividade contra sistemas potencialmente vulneráveis, mas não comprova invasões bem-sucedidas. Um serviço indisponível, por sua vez, pode estar em manutenção ou ter sido isolado preventivamente; a causa precisa ser verificada caso a caso.

O que muda para visitantes e administradores?

Quem apenas navega não precisa atualizar PHP no próprio computador. A correção cabe aos responsáveis pela infraestrutura. O administrador deve consultar a hospedagem, confirmar qual versão atende o site e combinar a atualização, com cópia de segurança e checagem de compatibilidade.

As versões corrigidas são 8.5.12, 8.4.27, 8.3.36 e 8.2.35, lançadas em 21 de outubro. A equipe técnica também deve reiniciar os serviços necessários e verificar se a correção está efetivamente em uso. Para instalações antigas, há correções adaptadas em determinadas distribuições e versões; é preciso consultar o fornecedor.

O CERT-EU recomenda considerar o isolamento de aplicações expostas à internet quando não for possível corrigi-las imediatamente. Um firewall de aplicações, como o oferecido pela Cloudflare, filtra tráfego suspeito e acrescenta uma camada de defesa, mas não remove o defeito do software.

A proteção adicional não substitui a correção do servidor.

Em pesquisa separada, publicada em 20 de outubro, a Anthropic relatou 493 problemas em 25 projetos analisados com Claude; alguns não eram exploráveis isoladamente. O estudo trata de reduzir trechos de código desnecessariamente expostos, outra frente de segurança com apoio de IA, e não da descoberta dessas duas falhas no PHP.

---

Perguntas frequentes

A IA derrubou os sites? ＋

Os comunicados não comprovam essa relação. Uma indisponibilidade, sozinha, não mostra se houve ataque nem qual tecnologia foi usada.

Preciso atualizar meu navegador? ＋

Atualizar o navegador não corrige esse problema: o PHP afetado está no servidor do site.

Todo WordPress foi invadido? ＋

Não. Usar PHP não é evidência de invasão. A situação depende da instalação e da investigação de cada ambiente.

Meus dados vazaram? ＋

A existência de uma vulnerabilidade não confirma vazamento. Essa conclusão exige evidências de comprometimento do serviço.

Por que tirar um site do ar? ＋

O isolamento pode reduzir a exposição enquanto a equipe aplica e verifica a correção.

Um firewall resolve sozinho? ＋

Não. Ele pode bloquear tráfego malicioso, mas a atualização do PHP continua necessária.