Ataques com IA saíram da teoria no dia 21 de outubro. Naquela quarta-feira, órgãos públicos brasileiros e sites de governos da Europa e de outras regiões ficaram fora do ar depois que falhas críticas no PHP foram descobertas com ajuda de inteligência artificial. No Brasil, caiu o SEI, sistema que órgãos públicos usam para tramitar documentos e processos.
A primeira reação é imaginar uma superinteligência hackeando o mundo. A realidade é menos cinematográfica e mais incômoda: a falha não foi inventada pela IA. Ela já estava lá. A IA só encontrou antes.
É isso que muda o jogo para a sua empresa. Neste artigo você vai entender o que aconteceu, o que a IA mudou de fato nos ataques (e o que não mudou) e sete ações práticas para reduzir o risco já.
O que foi o PHP2Shell
O PHP é a linguagem que roda boa parte dos sites da internet, incluindo praticamente todo site em WordPress. As duas falhas, apelidadas de PHP2Shell, receberam nota 9,2 de gravidade e permitem que um invasor, sem login, execute código no servidor. O resultado pode ser vazamento de dados e serviços fora do ar.
Três detalhes tornam o caso exemplar:
- 01
O ataque começou antes da correção.
Honeypots da Amazon registraram tentativas de exploração em 17 de outubro, quatro dias antes de existir o patch.
- 02
A escala é enorme.
Um levantamento da Censys de 22 de outubro identificou cerca de 36,7 milhões de serviços na internet com versões do PHP potencialmente afetadas.
- 03
Atualizar o site não resolve.
A falha está no motor do PHP, não no CMS nem nos plugins. Atualizar o WordPress dá falsa sensação de segurança.
Em 27 de outubro, a CISA, agência de cibersegurança dos EUA, confirmou que as falhas já estavam sendo exploradas em ataques reais.
O que a IA mudou (e o que não mudou)
Circula por aí a ideia de que as defesas tradicionais ficaram obsoletas. Não ficaram. Essa frase costuma vir de quem quer vender a próxima ferramenta mágica.
A ESET analisou cinco casos reais de ataques com IA em 2026 e chegou a uma conclusão clara: os incidentes não usaram técnicas inéditas. Exploraram vulnerabilidades conhecidas, configurações inseguras e autenticação fraca. A diferença foi a velocidade e a autonomia com que os modelos encontraram e encadearam essas brechas.
Em outras palavras: a IA não abre portas novas. Ela testa todas as portas da sua empresa, ao mesmo tempo, sem cansar.
Dois números mostram os dois lados:
- 01
Velocidade
o Google observou uma operação em que atacantes comprometeram um recurso na nuvem e montaram uma campanha de roubo de credenciais em menos de seis horas.
- 02
Proporção
segundo a VulnCheck, das 1.061 vulnerabilidades encontradas com IA no primeiro semestre de 2026, apenas 14 foram de fato exploradas (1,3%).
O segundo número tira o pânico, mas não a responsabilidade. Nem toda falha vira ataque. O problema é que você não sabe qual vai virar, nem quando.
A janela de correção encolheu
Até pouco tempo atrás o ciclo era previsível: sai a correção, a TI agenda a atualização para o próximo fim de semana ou para o mês seguinte, e a vida segue.
Esse ciclo morreu. Se o atacante leva horas para transformar uma falha em ataque e sua empresa leva 30 dias para aplicar a correção, a conta não fecha. No PHP2Shell, o ataque chegou antes da correção.
A pergunta certa deixou de ser "estamos protegidos?". Passou a ser: quanto tempo levamos para corrigir algo crítico que está exposto na internet? Se ninguém na sua empresa sabe responder, esse é o primeiro problema.
Onde a Cloudflare ajuda, e onde ela não alcança
Nessa história teve quem dormiu tranquilo. A Cloudflare liberou regras de WAF (firewall de aplicação web) contra o PHP2Shell cerca de 9 horas antes da divulgação pública. Desde a madrugada de 21 de outubro, clientes com WAF gratuito ou pago já estavam protegidos por padrão, antes mesmo de saber que o problema existia.
A empresa também estreou uma forma nova de detecção, que cruza sinais da requisição e da resposta na mesma transação e consegue barrar a resposta do servidor antes que ela chegue ao atacante.
Mas WAF não conserta o PHP, e a própria Cloudflare reconhece: o bloqueio impede que dados vazem, mas não desfaz o que já foi executado no servidor de origem. Na prática, há dois pontos cegos:
- 01
IP de origem exposto.
O WAF só protege o tráfego que passa por ele. Se o atacante descobre o IP real do servidor (por um subdomínio esquecido, um registro DNS antigo ou o cabeçalho de um e-mail enviado pelo próprio servidor), ele fala direto com o PHP vulnerável, e o WAF nem fica sabendo.
- 02
Variações que continuam surgindo.
Em 23 de outubro apareceu uma falha relacionada (CVE-2026-115560) que afeta até versões já corrigidas, incluindo a 8.5.12. O WAF só cobre essa variação se o site mantiver a configuração padrão do PHP.
O WAF compra tempo e reduz a exposição. Quem resolve é a correção. As duas coisas andam juntas.
7 ações para fazer agora
- Saiba o que está exposto. Liste tudo que sua empresa tem acessível pela internet: site, portal de clientes, VPN, ERP web, painéis de administração, câmeras. Ninguém corrige o que não sabe que existe.
- Defina prazo de correção por gravidade. Falha crítica em sistema exposto não pode esperar a janela do mês. Estabeleça um prazo curto e cobre.
- Confirme a versão do PHP com a hospedagem. As versões corrigidas são PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Peça confirmação por escrito, não apenas "está tudo certo". E acompanhe os próximos avisos: a falha relacionada de 23/10 ainda aguarda correção.
- Coloque sites e portais atrás de um WAF e feche a origem. Cloudflare na frente e, no firewall do servidor (um FortiGate, por exemplo), libere conexões web só a partir dos IPs da Cloudflare. Sem isso, um IP descoberto vira porta dos fundos.
- Exija MFA em todo acesso externo. E-mail, VPN, painel do site, ERP. Senha sozinha não segura um atacante automatizado.
- Corte acessos e credenciais sobrando. Em um dos incidentes analisados pela ESET, um modelo de IA comprometeu uma aplicação real usando credenciais expostas em uma página de depuração e uma falha de injeção de SQL. Contas antigas, senhas em arquivos e acessos de ex-fornecedores são as portas mais fáceis.
- Tenha detecção, não só prevenção. Firewall com IPS atualizado e monitoramento avisam quando algo estranho acontece. Junto disso, backup fora do servidor e testado. Backup que nunca foi restaurado é só uma esperança.
E a tal "defesa preditiva com IA"?
Ferramentas de segurança com IA são úteis e já fazem parte dos bons firewalls, WAFs e soluções de endpoint. Elas detectam comportamento anormal mais rápido que qualquer pessoa.
Mas não substituem o básico. Comprar plataforma de IA sem saber o que está exposto, sem MFA e com servidor desatualizado é investir na ponta errada.
Conclusão
O PHP2Shell não foi o primeiro caso e não será o último. A IA acelerou os dois lados: quem defende encontra falhas mais rápido, e quem ataca também.
Para sua empresa, a lição é prática. Os fundamentos continuam valendo (inventário, atualização, WAF, MFA, menor privilégio, detecção e backup), só que agora precisam ser executados com velocidade. Segurança deixou de ser um projeto que se faz uma vez e virou rotina com prazo.
Na Allconnection, começamos sempre pelo mesmo ponto: descobrir o que sua empresa tem exposto e quanto tempo ela leva para corrigir.
Quer saber o que sua empresa tem exposto na internet hoje? Fazemos um diagnóstico de exposição para mostrar onde estão as portas abertas.
Fale com a gente: allconnection.com.br | (54) 2621-5775
Fontes
- Jornal do Comércio: falha descoberta por IA tira sites de governos do ar
- ESET WeLiveSecurity: ataques com IA em 2026, o que 5 casos reais revelam
- Fortinet: entendendo o PHP2Shell e reduzindo o risco enquanto corrige
- BleepingComputer: CISA confirma exploração do PHP2Shell
- Cloudflare: proteções de WAF contra o PHP2Shell
- Cloudflare: detecção de transação completa no WAF
- Cloudflare: desafio PHP Capture the Flag