Bloom Security encontra vulnerabilidade na publicação de pacotes, e agentes de IA ampliam o risco

Em 2025, pesquisadores analisaram 576 mil trechos de código escritos por 16 modelos. Em média, 19,7% dos pacotes recomendados simplesmente não existiam. Esses nomes podem ser registrados e preenchidos com código malicioso, bastando depois esperar que o assistente de IA os puxe para o projeto por conta própria. Agora o problema ganhou mais uma camada: a Bloom Security descreveu uma vulnerabilidade na infraestrutura de publicação de software que, combinada a instalações automáticas, pode levar código malicioso a um ambiente corporativo. A informação é do The Next Web.

O que se sabe sobre a vulnerabilidade

Os detalhes técnicos na parte acessível da publicação são limitados, por isso é importante não especular. O que se sabe é o seguinte: a Bloom Security encontrou um ponto fraco nos mecanismos de publicação de pacotes, e ele fica mais perigoso quando quem instala as dependências não é uma pessoa, mas um agente de IA. Pelo endereço da reportagem, trata-se do mecanismo Trusted Publishing do npm.

Nesse esquema, o pacote é publicado a partir de um processo de CI confiável, sem tokens de longa duração. A ideia é razoável: tokens são roubados com frequência e, depois da onda de ataques ao npm em 2025, incluindo o worm Shai-Hulud, que afetou centenas de pacotes, o ecossistema revisou com seriedade suas práticas de publicação.

Uma vulnerabilidade no próprio mecanismo de confiança atinge a premissa básica: se o pacote foi publicado da maneira "correta", pode-se confiar nele. O agente compartilha essa premissa e não vai verificá-la.

Por que os agentes mudam a escala

Quem instala uma dependência costuma pelo menos dar uma olhada rápida no nome, no número de downloads e no repositório. O agente funciona de outra forma: ele precisa que os testes passem e que o build seja concluído. Se o pacote resolve a tarefa, ele vai parar no `package.json` em segundos.

Três fatores se reforçam mutuamente:

• Velocidade. Um agente pode instalar dezenas de dependências em uma única sessão, e cada uma vira um ponto de entrada.
• Alucinações de nomes. Cerca de 20% de pacotes inexistentes nas respostas dos modelos, segundo o estudo de 2025, criam espaço para ataques por meio do registro de nomes parecidos.
• Permissões. Os agentes costumam trabalhar em ambientes com acesso a segredos, CI e repositórios internos, e os scripts de instalação do npm são executados imediatamente.

A vulnerabilidade na publicação acrescenta mais um vetor: mesmo o nome correto de um pacote deixa de garantir segurança.

Quem é afetado

O maior risco está nas equipes em que a programação com IA entrou no fluxo de trabalho sem uma política específica para dependências: startups com ciclo rápido de lançamentos, prestadoras de serviço e equipes internas de plataforma. As áreas de segurança corporativa estão acostumadas a controlar pessoas e pipelines, mas o agente fica entre os dois e contorna ambos os níveis de controle.

Ainda não está claro em que medida a falha foi explorada na prática nem quais versões são afetadas. Essas perguntas devem ser feitas ao responsável pelo registro e aos próprios pesquisadores.

O que fazer agora

Primeiro, vale descobrir quais agentes da empresa podem executar `npm install` e em que ambiente. Se for a máquina do desenvolvedor, com tokens e acesso a repositórios privados, essa é a primeira área a restringir.

Depois, funcionam medidas já conhecidas:

• ativar arquivos de lock e proibir que os agentes os alterem sem revisão;
• desativar a execução de scripts de instalação (`--ignore-scripts`) onde eles não forem necessários;
• criar uma allowlist de dependências ou um espelho interno do registro, com atraso para novas versões;
• verificar pacotes novos por idade, número de mantenedores e origem do build;
• executar os agentes em sandboxes isoladas, sem segredos permanentes.

A conclusão principal é simples: a confiança no registro deve ser verificada da mesma forma que a confiança no código, e a velocidade do agente não pode superar a velocidade da verificação.