Nas últimas semanas, uma sequência de incidentes chamou atenção de quem acompanha tecnologia e segurança.

Falhas críticas em PHP fizeram sites e serviços públicos serem retirados do ar.

Um pacote Python amplamente utilizado em aplicações de IA foi comprometido e passou a executar código malicioso automaticamente em ambientes onde estava instalado.

Grupos patrocinados por estados passaram a usar agentes de IA para automatizar reconhecimento, tentativas de autenticação e movimentação em ambientes cloud.

Pesquisadores também encontraram vulnerabilidades em frameworks de agentes capazes de transformar prompt injection em execução remota de código.

E, em paralelo, um hacker conseguiu usar agentes autônomos para atacar mais de mil sites com pouca supervisão humana.

O ponto mais importante é que esses acontecimentos não são todos o mesmo tipo de problema.

Não existe uma explicação simples como:

“A IA hackeou a internet.”

O que estamos vendo é uma combinação de quatro movimentos:

A IA está acelerando tanto o lado defensivo quanto o ofensivo.

Ao mesmo tempo, nossa dependência de linguagens, pacotes, frameworks e serviços compartilhados faz com que uma única falha possa atingir milhares ou milhões de sistemas.

O que vamos entender

• O que aconteceu com PHP.
• Por que milhões de tentativas de exploração surgiram tão rápido.
• Como uma falha em Python pode afetar muito mais do que um único projeto.
• O caso do LiteLLM 1.107.0.
• O que é um ataque de supply chain.
• Como agentes de IA estão automatizando ataques reais.
• O que aconteceu no caso ARTEX / Storm-0940.
• Como um único hacker atacou mais de 1.200 sites com agentes.
• Por que frameworks de IA criam novas superfícies de ataque.
• Como prompt injection pode virar execução de código.
• Por que o problema não é “PHP ruim” ou “Python inseguro”.
• O que muda para desenvolvedores.
• Como reduzir risco em projetos modernos.

Não é uma linguagem específica que “deu ruim”

Quando surgem incidentes em linguagens populares, é comum aparecer uma conclusão rápida:

PHP é inseguro

ou:

Python virou problema

Essa leitura é simplista.

Linguagens populares aparecem mais em incidentes porque estão em muitos lugares.

O problema real costuma estar em uma combinação de:

• vulnerabilidade;
• versão desatualizada;
• cadeia de dependências;
• configuração;
• credenciais;
• automação;
• velocidade do atacante.

PHP: uma falha pode atingir uma parte enorme da web

PHP continua sendo uma das tecnologias mais presentes na web.

Segundo dados citados pela Reuters a partir da W3Techs, a linguagem é utilizada por quase 70% dos sites em que a linguagem server-side é identificável.

Isso significa que qualquer falha crítica em componentes centrais do PHP possui um potencial de impacto enorme.

Em outubro de 2026, duas vulnerabilidades críticas foram divulgadas.

Ambas receberam pontuação:

CVSS 9.2 / 10

e poderiam permitir execução remota de comandos sem autenticação em cenários vulneráveis.

O mais impressionante: as falhas ficaram escondidas por anos

Pesquisadores relataram que os problemas existiam há muito tempo.

A novidade foi conseguir demonstrar caminhos de exploração confiáveis.

E aqui aparece a IA.

Pesquisadores de segurança utilizaram ferramentas de inteligência artificial para ajudar a encontrar e analisar essas vulnerabilidades.

Isso é importante porque mostra que IA não está apenas criando ataques.

Ela também está ajudando pesquisadores a encontrar problemas que passaram despercebidos durante anos.

Quantos sistemas estavam potencialmente expostos?

A escala foi enorme.

A Censys estimou aproximadamente:

2,6 milhões

de hosts observados dentro do universo analisado.

Destes, cerca de:

1,5 milhão

estavam executando versões vulneráveis sem correção disponível naquele momento.

Isso não significa que 1,5 milhão de servidores tenham sido invadidos.

Significa:

havia uma quantidade gigantesca de sistemas potencialmente expostos.

Essa diferença importa.

Exploração passou de milhares para milhões de tentativas

Depois da divulgação pública, a atividade ofensiva cresceu rapidamente.

A Cloudflare relatou que tentativas de exploração passaram de milhares para milhões.

Esse é um dos pontos centrais do cenário atual.

A janela entre:

falha divulgada

e:

exploração em massa

está ficando cada vez menor.

Governos e empresas tiraram sistemas do ar

A situação foi séria o bastante para provocar respostas emergenciais.

Sites e serviços foram temporariamente desligados em diferentes países enquanto equipes aplicavam patches e testavam ambientes.

Entre os setores citados estavam:

• governos;
• bancos;
• companhias aéreas;
• ferrovias;
• seguradoras;
• portais públicos.

Isso mostra como uma vulnerabilidade em uma linguagem amplamente usada pode sair da bolha de desenvolvimento e afetar serviços do mundo real.

O problema não era WordPress

Como PHP é muito associado a WordPress, muita gente assume:

“é só atualizar o WordPress.”

Mas nesse caso o problema estava abaixo da aplicação.

Se a vulnerabilidade está no runtime PHP, atualizar apenas o CMS não resolve.

Essa distinção é importante.

Python: outro tipo de problema

No caso recente do Python, a história é diferente.

Não foi uma vulnerabilidade geral da linguagem.

O incidente envolveu um pacote distribuído pelo PyPI:

LiteLLM 1.107.0

A versão publicada foi comprometida.

Isso é um exemplo clássico de:

supply chain attack

ou ataque à cadeia de fornecimento de software.

O que é supply chain attack?

Imagine que seu projeto confia em uma dependência.

Se o pacote legítimo for comprometido:

O atacante não precisa invadir cada empresa individualmente.

Ele compromete um ponto central da cadeia.

O caso LiteLLM foi particularmente perigoso

LiteLLM é utilizado como gateway entre aplicações e diferentes provedores de modelos.

Esse tipo de software pode ter acesso a:

• chaves de API;
• credenciais cloud;
• bancos;
• configurações;
• tokens;
• variáveis de ambiente.

A versão comprometida adicionou mecanismos que o Python podia executar durante a inicialização do interpretador.

E aqui está a parte preocupante:

a aplicação não precisava importar explicitamente LiteLLM para o código malicioso executar.

Em determinados ambientes, apenas iniciar o Python poderia ser suficiente.

Por que isso é tão grave?

Normalmente imaginamos:

import pacote_malicioso

como ponto de execução.

Mas o incidente explorou mecanismos de inicialização.

Isso amplia muito o escopo da investigação.

Não era apenas o servidor do LiteLLM

A Microsoft alertou que ambientes afetados poderiam incluir:

• workstations de desenvolvedores;
• agentes de CI/CD;
• ambientes de teste;
• containers;
• gateways de IA;
• hosts de aplicações.

Ou seja:

pacote comprometido

poderia atingir vários pontos da cadeia de desenvolvimento.

O alvo principal: credenciais

O malware procurava informações sensíveis.

Entre os alvos estavam:

• chaves de provedores de IA;
• credenciais cloud;
• tokens de source control;
• SSH;
• dados de browser;
• variáveis de ambiente;
• credenciais de banco.

Isso mostra uma mudança importante no valor dos ambientes de desenvolvimento.

Hoje um notebook de desenvolvedor pode conter acesso a:

GitHub
AWS
Azure
GCP
Vercel
npm
PyPI
Docker Registry
OpenAI
Anthropic
bancos

Comprometer um developer machine pode abrir portas muito maiores.

PHP e Python mostram dois riscos diferentes

Podemos resumir assim:

Um caso explora a ubiquidade de uma linguagem.

O outro explora confiança em dependências.

Agora entra a IA ofensiva

Até aqui falamos de vulnerabilidades e supply chain.

Mas existe outro movimento acontecendo:

agentes autônomos atacando sistemas

Não é apenas um modelo gerando um script.

São agentes capazes de executar ciclos como:

Isso se aproxima muito mais de um operador autônomo.

Storm-0940 e ARTEX

A Microsoft publicou uma investigação sobre o grupo Storm-0940.

Segundo a empresa, o grupo utilizou o framework agentic AI:

ARTEX

para automatizar ataques contra centenas de organizações.

Os setores atingidos incluíam:

• defesa;
• energia;
• finanças;
• governo;
• indústria;
• mídia;
• semicondutores;
• tecnologia.

Menos de três horas até acesso privilegiado

Em vários casos observados, o tempo entre:

primeiro alvo

e:

acesso privilegiado em cloud

foi inferior a:

3 horas

Isso muda a dinâmica de resposta.

Antes uma equipe talvez tivesse horas ou dias para reagir.

Agora:

A velocidade virou parte da ameaça.

2.900 tentativas por minuto

Em um subconjunto da campanha, a Microsoft observou:

2.900 tentativas de login por minuto

Também foram registrados:

151.000+ logins falhos

em uma campanha automatizada.

E o alcance chegou a mais de:

2.250 tenants

Esse tipo de escala mostra por que agentes são tão relevantes.

Um humano não executaria manualmente milhares de tentativas distribuídas nesse ritmo.

Mas automação não significa sucesso automático

Existe um detalhe importante.

Apesar do volume enorme, boa parte das tentativas falhou.

Esse ponto precisa ser dito para evitar sensacionalismo.

IA aumenta escala
≠
IA garante invasão

O ganho está em:

• velocidade;
• paralelismo;
• persistência;
• custo menor;
• capacidade de tentar muitos alvos.

Um hacker, 1.200 sites e cerca de US$ 5.000

Outro caso recente ajuda a entender a economia desse novo modelo.

Segundo pesquisa relatada pela Reuters, um hacker utilizou agentes de IA para tentar comprometer mais de:

1.200 sites

As vítimas estavam em países como:

• Estados Unidos;
• Canadá;
• Austrália;
• Japão.

Mais de:

100 empresas

foram comprometidas, segundo o pesquisador citado.

O custo chama atenção

A campanha inteira teria consumido aproximadamente:

US$ 5.000

em uso de IA.

Em alguns casos, um ataque bem-sucedido custava em torno de:

US$ 50

e podia envolver aproximadamente:

23 horas

de probing autônomo.

A grande mudança é econômica.

Ataques complexos ficam mais baratos de escalar.

IA ofensiva não precisa ser genial

Talvez esse seja um dos maiores equívocos.

Um agente não precisa descobrir uma vulnerabilidade revolucionária.

Ele pode ser útil simplesmente por:

não cansar
+
testar muita coisa
+
ler resultados
+
ajustar estratégia
+
continuar

Essa persistência automatizada já cria valor ofensivo.

O outro problema: agentes viraram superfície de ataque

Até agora vimos:

IA sendo usada para atacar

Mas existe também:

IA sendo atacada

Frameworks de agentes conectam modelos a ferramentas.

Isso significa que o modelo pode:

• ler arquivos;
• consultar bancos;
• chamar APIs;
• executar scripts;
• usar terminal.

Essa capacidade transforma um problema de linguagem natural em um problema de segurança de sistema.

Quando prompt vira shell

Pesquisadores da Microsoft encontraram vulnerabilidades críticas no Semantic Kernel.

Em um dos casos, uma prompt injection poderia levar a:

Remote Code Execution

no host executando o agente.

Essa é uma mudança importante de threat model.

O modelo não precisa estar “hackeado”

O problema pode estar no framework.

O modelo faz exatamente aquilo que foi projetado para fazer:

interpretar linguagem
↓
escolher ferramenta
↓
enviar parâmetros

Se a ferramenta confia demais nesses parâmetros, temos vulnerabilidade.

Agentes aumentam o princípio do privilégio

Quanto mais capacidades um agente possui:

arquivos
+
terminal
+
cloud
+
banco
+
e-mail
+
GitHub

mais perigoso fica um erro.

Isso é parecido com dar uma conta administrativa para um funcionário extremamente rápido, mas ainda sujeito a interpretar instruções incorretamente.

Então quantos sistemas estão realmente sendo impactados?

Essa pergunta precisa ser respondida com cuidado.

Não existe um único número global.

Estamos falando de eventos diferentes:

Esses números não devem ser somados.

Eles representam métricas diferentes.

Mas juntos mostram uma coisa:

a escala operacional da cibersegurança está mudando.

Quais tecnologias estão no centro?

Não é apenas PHP e Python.

O cenário atual envolve várias camadas:

Qualquer ponto dessa cadeia pode virar entrada.

JavaScript e npm também entram na conversa

Ecossistemas com muitos pacotes sempre foram alvos interessantes para supply chain.

npm é um dos maiores exemplos.

Projetos JavaScript frequentemente dependem de:

centenas

ou até:

milhares de pacotes

indiretos.

Mesmo sem um incidente específico igual ao LiteLLM neste artigo, o princípio é o mesmo:

confiança transitiva

Você confia em um pacote.

Esse pacote confia em outro.

E assim por diante.

Java, .NET e cloud também não estão fora

As campanhas agentic observadas pela Microsoft não dependiam de uma linguagem específica.

Elas atuavam contra:

• identidades;
• OAuth;
• Microsoft 365;
• cloud;
• service principals;
• aplicações web.

Isso mostra que a próxima geração de ataques pode ser menos sobre:

qual linguagem seu sistema usa?

e mais sobre:

qual caminho dá acesso?

O alvo passou a ser o ecossistema inteiro

Um atacante moderno pode procurar:

O objetivo é encontrar o elo mais fraco.

Por que IA muda tanto a velocidade?

Porque muitas tarefas de segurança envolvem linguagem e interpretação.

Por exemplo:

• ler documentação;
• interpretar erro;
• analisar HTML;
• entender API;
• escrever script;
• comparar respostas;
• procurar endpoints.

Essas são justamente tarefas em que LLMs são fortes.

Antes e depois

Sem agentes:

Com agentes:

O humano continua importante.

Mas precisa atuar menos em cada tentativa individual.

A mesma IA ajuda defensores

Não podemos olhar apenas para o lado ofensivo.

Os incidentes do PHP são um exemplo interessante.

IA ajudou pesquisadores a encontrar falhas críticas escondidas durante anos.

Defensores também utilizam IA para:

• analisar logs;
• priorizar alertas;
• encontrar código vulnerável;
• revisar dependências;
• detectar padrões;
• automatizar investigação.

É uma corrida.

O verdadeiro problema é velocidade

Talvez o ponto mais importante deste artigo seja esse:

o intervalo entre descoberta, divulgação e exploração está diminuindo.

Antes:

falha
↓
pesquisa
↓
exploit
↓
automação

Agora essas etapas podem se comprimir.

Isso muda completamente o valor de patch rápido.

“Atualizo semana que vem” pode não funcionar mais

Em um cenário onde exploração em massa surge horas depois da divulgação:

patch amanhã

pode ser tarde.

Principalmente para sistemas expostos diretamente à internet.

O que muda para desenvolvedores?

Se você trabalha com:

React
Next.js
Python
PHP
Node
Java
.NET

esse cenário afeta sua rotina.

Segurança não pode ficar apenas para:

“o time de segurança”

1. Dependências precisam ser tratadas como código seu

Quando você instala:

npm install

ou:

pip install

você está executando código de terceiros no seu ecossistema.

Então vale:

• lockfile;
• pin de versões;
• revisão;
• scanners;
• atualização;
• origem confiável.

2. Não use tags mutáveis em produção

Containers como:

latest

podem mudar.

Prefira, quando possível:

digest imutável

Isso reduz risco de receber artefatos diferentes sem perceber.

3. CI/CD é infraestrutura crítica

Build agents possuem acesso a:

• repositórios;
• tokens;
• registry;
• deploy;
• cloud.

Por isso comprometê-los pode ser muito valioso.

Trate pipeline como produção.

4. Credencial vazada deve ser revogada

Não basta:

apagar do GitHub

Se uma secret foi publicada:

considere comprometida

Faça rotação.

Esse foi um dos pontos destacados em campanhas recentes observadas pela Microsoft.

5. Agentes precisam de menos permissão

Não dê ao agente:

acesso total ao sistema

se ele precisa apenas ler um arquivo.

Aplique:

least privilege

também para IA.

6. Prompt é entrada não confiável

Se seu agente recebe conteúdo externo:

site
documento
e-mail
API

trate aquilo como entrada potencialmente maliciosa.

7. Isolamento virou requisito

Agentes capazes de executar código deveriam operar em:

• sandbox;
• container;
• VM;
• ambiente com rede limitada;
• filesystem restrito.

O princípio é:

se der errado
↓
o dano precisa parar ali

Não existe “linguagem segura”

PHP pode ter vulnerabilidade.

Python pode ter supply chain compromise.

Node pode sofrer pacote malicioso.

Java pode ter dependência vulnerável.

C e C++ possuem riscos de memória.

Rust reduz algumas classes de erro, mas não elimina falhas de lógica.

Segurança não é propriedade exclusiva da linguagem.

A pergunta certa é outra

Em vez de perguntar:

Qual linguagem é segura?

Pergunte:

Como esse sistema recebe atualizações?
Quais dependências ele usa?
Onde ficam as credenciais?
Quem pode executar código?
Quais permissões existem?
Quanto tempo demoramos para corrigir?

Essas perguntas importam muito mais.

A IA vai substituir hackers?

Provavelmente não é a melhor forma de pensar.

O cenário mais realista é:

hacker
+
IA

assim como desenvolvedores usam:

dev
+
IA

O especialista ganha escala.

Um atacante pode operar mais alvos ao mesmo tempo

Antes:

1 operador
↓
poucos alvos simultâneos

Agora:

Esse paralelismo é o que realmente preocupa.

✅ Resultado Final

O que estamos vendo em 2026 não é uma única “onda de hacks por IA”.

São vários fenômenos acontecendo ao mesmo tempo:

1. IA ajudando pesquisadores a encontrar vulnerabilidades antigas.
2. Ataques automatizados surgindo mais rápido após divulgação.
3. Supply chain compromises atingindo ecossistemas de desenvolvimento.
4. Agentes ofensivos atacando centenas ou milhares de alvos.
5. Frameworks de agentes criando novas superfícies de RCE.
6. Credenciais e cloud se tornando alvos prioritários.
7. Defensores usando IA para reagir à mesma velocidade.

PHP mostrou o risco de uma vulnerabilidade em tecnologia onipresente.

LiteLLM mostrou o risco da cadeia de dependências em Python.

ARTEX mostrou o que acontece quando agentes levam operações ofensivas para velocidade de máquina.

E as vulnerabilidades em frameworks de agentes mostram que a própria infraestrutura de IA também precisa ser protegida.

Considerações Finais

Talvez a maior mudança da IA na cibersegurança não seja a criação de um ataque completamente novo.

É a redução brutal do custo de fazer coisas que já existiam.

Reconhecimento.

Análise.

Scripts.

Tentativas.

Persistência.

Repetição.

Tudo isso pode ser automatizado.

O resultado é uma mudança de escala.

E esse cenário deixa uma lição importante para quem desenvolve software:

segurança agora também é uma corrida de velocidade.

Não basta ter patch.

É preciso aplicar rápido.

Não basta remover uma secret do Git.

É preciso revogar.

Não basta confiar que uma dependência famosa é segura.

É preciso verificar a cadeia.

E não basta criar um agente poderoso.

É preciso limitar o que ele consegue fazer quando algo dá errado.

A IA está dando mais capacidade aos defensores.

Mas também está dando escala aos atacantes.

E talvez essa seja a característica mais importante da nova fase da cibersegurança:

quem automatizar melhor, reage primeiro.

Referências

• Microsoft Security — AI-driven, large-scale nation-state campaign using ARTEX
• Microsoft Security — LiteLLM 1.107.0 supply chain compromise
• Microsoft Security — When prompts become shells
• Reuters — Hacking attempts surge as companies, governments rush to patch PHP flaws
• Reuters — What is PHP and why did it take government websites offline?
• Reuters — How one hacker used AI agents and a few thousand dollars to break into scores of sites