Voltar ao blog

Tecnologia e Segurança Digital

Quando a inteligência artificial acha a falha primeiro

O anúncio de duas falhas graves no PHP (chamadas de PHP2Shell) levou governos, empresas e órgãos públicos a desligarem preventivamente seus sistemas para evitar invasões. Embora essas vulnerabilidades existissem no código há décadas, o uso de inteligência artificial permitiu que fossem rapidamente transformadas em ataques viáveis, encurtando drasticamente o tempo de resposta e acelerando tentativas de exploração em massa por criminosos.

Elaine Meira Barros23 de outubro de 2026
Quando a inteligência artificial acha a falha primeiro

Texto por: Elaine Meira Barros

Na quarta-feira, 21 de outubro, quem tentou abrir um processo no sistema eletrônico da Anatel encontrou a página fora do ar. A agência desligou o sistema às 12h15, por precaução, e só voltou a ligá-lo às 22h05. No mesmo dia, os tribunais regionais federais de Porto Alegre, Brasília e Belo Horizonte cortaram o acesso externo aos seus sistemas, e o de Belo Horizonte chegou a suspender prazos processuais. No Japão, o governo, um banco, uma companhia aérea e uma ferrovia tiraram páginas do ar. Na Europa, França, Alemanha, Holanda e Dinamarca fizeram o mesmo com sites oficiais. Até a Wikipédia desligou parte dos seus serviços.

O motivo do apagão voluntário foi o anúncio de duas falhas graves no PHP, a linguagem de programação em que foi escrita boa parte da internet. Cerca de 70% dos sites cuja tecnologia de servidor se conhece usam PHP, inclusive os feitos em WordPress, a plataforma mais comum entre blogs, lojas virtuais e páginas de pequenas empresas. As duas falhas, batizadas de PHP2Shell, permitem que um invasor assuma o controle do servidor que hospeda o site sem precisar de senha. A equipe do PHP deu nota 9,2, numa escala que vai até 10, para a gravidade de cada uma. Até agora não há confirmação pública de invasão bem-sucedida, e os órgãos que desligaram seus sistemas disseram que agiram para evitar uma.

O que a IA mudou

As duas falhas estavam no código do PHP havia décadas, sem que ninguém conseguisse transformá-las num ataque. Em agosto, a empresa de segurança Calif encontrou uma delas numa auditoria do PHP financiada pela OpenAI, com a ajuda de um modelo de inteligência artificial da própria OpenAI. A Wiz, empresa de segurança que pertence ao Google, encontrou as duas por conta própria, também com modelos de IA. Segundo a Wiz, o que a IA mudou foi a capacidade de entender o defeito e transformá-lo num ataque que funciona. Um único pesquisador fez em uma semana o que antes levaria meses de trabalho de uma equipe de primeira linha.

Essa é a parte que deveria preocupar quem não trabalha com tecnologia. Se a IA ajuda um pesquisador honesto a achar em semanas uma falha que passou décadas despercebida, ajuda também um criminoso. E o dia 21 mostrou quanto encolheu o tempo entre a descoberta e o ataque. Detalhes das falhas vazaram antes da data marcada, e a Cloudflare, empresa americana de infraestrutura e segurança da internet, registrou milhares de tentativas de explorá-las nas dez horas anteriores ao anúncio oficial. Depois do anúncio, as tentativas passaram a dezenas de milhares em 45 minutos, centenas de milhares em duas horas e milhões ao longo do dia. A correção saiu no mesmo dia, mas quem não a aplicou na hora ficou exposto. Por isso o FBI e o governo japonês deram a mesma orientação: se não der para atualizar, tire o site do ar.

Como a falha chega a quem nunca ouviu falar de PHP

Uma falha num servidor parece assunto de técnico. Ela vira problema de qualquer pessoa porque é nos servidores que ficam os dados que deixamos pela internet. Pense na loja virtual onde você comprou um presente, na clínica que marca consultas pelo site, na escola dos filhos, na prefeitura da cidade. Muitos desses sites rodam em PHP, e muitos guardam nome, CPF, endereço, telefone e senha de quem se cadastrou. Quem entra no servidor pode copiar esse cadastro. Segundo os pesquisadores, o PHP2Shell também permite ler partes da memória do servidor, onde costumam passar senhas e chaves de acesso.

O cadastro roubado de uma loja raramente é usado na hora. Ele vai parar em listas negociadas entre criminosos e volta meses depois em forma de golpe: um e-mail com o seu nome completo e o número do seu último pedido, uma mensagem de um falso atendente que sabe o que você comprou, uma ligação de alguém que confirma o seu CPF antes de pedir um código. Quanto mais o golpista sabe, mais fácil é acreditar nele. Por isso a vítima de uma falha como essa pode nunca ter ouvido falar de PHP.

Há um segundo caminho. Quem controla o servidor controla também o que o site mostra. A loja de um comerciante honesto pode passar a exibir uma página de pagamento falsa ou a oferecer um arquivo contaminado para baixar. O cliente faz tudo certo, digita o endereço de sempre e cai no golpe mesmo assim. Esse tipo de adulteração costuma demorar a ser percebido, porque o dono do site continua vendo a loja como sempre foi.

O terceiro caminho nem depende da falha. Notícia que assusta vira isca. É provável que, nas próximas semanas, circulem e-mails de falsos provedores de hospedagem avisando que o seu site está vulnerável e pedindo um clique para corrigir, ou mensagens que oferecem um aplicativo contra a falha do PHP. Esse golpe usa um medo verdadeiro para fazer a pessoa agir sem pensar.

O risco dobrado de quem tem um pequeno negócio

Quem tem um negócio com site próprio pode ser vítima duas vezes: perde dados e dinheiro, e o site pode virar, sem que ninguém saiba, a porta de entrada para golpes contra os próprios clientes.

A dona de uma confeitaria com site em WordPress, num plano barato de hospedagem, provavelmente nunca soube em que versão do PHP o site roda. Quem decide isso é a empresa de hospedagem, ou o sobrinho que montou o site há cinco anos. E aqui está a armadilha: atualizar o WordPress e os plugins, o que muita gente faz pelo painel, não corrige o PHP2Shell. A correção precisa acontecer no servidor, no próprio PHP.

A situação é pior para quem está numa versão antiga. O projeto PHP só publicou versões corrigidas para as séries 8.2, 8.3, 8.4 e 8.5. Quem ainda usa o PHP 8.1 ou anterior, comum em sites antigos e em hospedagens que não se atualizam, depende de que o fornecedor aplique uma correção por conta própria, ou precisa migrar para uma versão nova. Essa migração nem sempre é simples, porque um site antigo pode parar de funcionar na versão nova e exigir ajustes. Muita gente adia, e cada mês de adiamento é um mês de porta aberta. Nem a série 8.2 é saída duradoura: ela deixa de receber correções de segurança em 31 de dezembro de 2026.

A Anatel e os tribunais tinham equipe para desligar e religar seus sistemas, e voltaram ao ar em horas. A maior parte dos sites pequenos não tem ninguém olhando. Especialistas esperam uma onda de invasões nas próximas semanas, e ela deve acontecer justamente nesses sites esquecidos. No próximo texto, mostramos o que fazer, como cliente e como dona de negócio, para não entrar nessa onda e para diminuir o prejuízo se o pior acontecer.

Fontes

• PHP.net, avisos de 20, 21 e 23 de outubro: CVEs, nota 9,2, versões corrigidas, fim das atualizações para 8.1 e anteriores

• PHP.net, versões com suporte: datas de fim do suporte de segurança

• CNN Brasil: horários da Anatel, alerta do governo federal via CTIR Gov

• Baguete: TRF1, TRF4 e TRF6, ausência de invasões confirmadas no Brasil

• Euronews: Calif, Wiz, vazamento antes da data, França, Alemanha, Holanda, Wikimedia

• CNN via ABC7: falhas antigas, leitura de memória, frase da Wiz sobre uma semana contra meses, Japão e Dinamarca

• Axios: números da Cloudflare, 70% dos sites (W3Techs), expectativa de onda de invasões

• AP via PBS: orientação do FBI e do governo japonês para tirar sites do ar

• Defesa em Foco: alerta de que atualizar WordPress e plugins não substitui a atualização do PHP

• CyberSec Brazil: tentativas de ataque antes da correção, sem comprometimento confirmado