Quando o seu assistente de programação inventa um pacote, os atacantes registam-no primeiro

Peça a um assistente de programação com IA para limpar os imports e ele pode devolver-lhe um nome de pacote que não existe. O nome parecerá plausível. Combinará duas ferramentas reais ou seguirá uma convenção de nomenclatura que reconhece. Você cola o comando de instalação e, se alguém já tiver registado esse nome, acabou de instalar tudo o que essa pessoa publicou.

Os investigadores de segurança chamam a isto slopsquatting. É parente do typosquatting, exceto que o atacante não precisa que você escreva nada mal. Só precisa de saber o que o modelo tende a inventar e, depois, ser o primeiro a reivindicar esse nome.

A escala não é anedótica

Um estudo da USENIX Security de 2025 testou 16 modelos de geração de código em 576.000 amostras de código em Python e JavaScript. Descobriu mais de 205.000 nomes de pacotes únicos que não existiam em nenhum registo. A taxa de alucinação foi de pelo menos 5,2% nos modelos comerciais e de 21,7% nos de código aberto. Um estudo de seguimento de 2026 testou cinco modelos de fronteira mais recentes e mediu taxas entre 4,62% e 6,10%, o que é mais baixo, mas continua presente em todos os modelos testados.

A parte que transforma uma peculiaridade numa superfície de ataque é a repetibilidade. Quando os investigadores repetiram prompts idênticos, uma grande parte dos nomes alucinados voltou a aparecer de cada vez. Os modelos não estão a adivinhar aleatoriamente; convergem nas mesmas respostas erradas porque aprenderam os mesmos padrões a partir dos mesmos dados de treino. Essa previsibilidade é a vulnerabilidade. Um atacante pode executar os mesmos prompts, recolher os nomes que se repetem e registá-los antes de qualquer outra pessoa.

O estudo de 2026 identificou 127 nomes de pacotes que os cinco modelos testados produziram apesar de não existirem, com 53 ainda disponíveis para registo depois de aplicadas as proteções dos registos.

Pacotes reais, instalações reais

Isto já aconteceu. No início de 2026, os investigadores encontraram um pacote chamado react-codeshift referenciado em 237 repositórios do GitHub. O nome mistura duas ferramentas reais, jscodeshift e react-codemod. Nunca tinha sido publicado. Uma skill gerada por IA que continha o pacote fictício tinha sido copiada e ramificada, deixando a referência espalhar-se sozinha.

Um pacote chamado metro-evaluator no npm continha código malicioso em quatro versões publicadas em dezembro de 2025, antes de ser removido cinco dias depois e substituído por um marcador de segurança. Os modelos testados tinham sugerido esse nome dez vezes. Outro, unused-imports, imitava o verdadeiro eslint-plugin-unused-imports e continuava a acumular instalações de programadores cujo assistente os apontava para ele.

A operação maior é uma campanha que a empresa de segurança Koi Security chama PhantomRaven, ativa desde pelo menos agosto de 2025. A Koi atribui-lhe 126 pacotes npm maliciosos e mais de 86.000 downloads. O truque aqui é diferente de um nome alucinado. O package.json parece limpo, às vezes contendo pouco mais do que uma linha de log, mas aponta para uma dependência alojada num URL HTTP simples em vez de outro pacote npm. A maioria dos scanners não segue URLs em bruto, por isso o payload que recolhe tokens do npm, credenciais do GitHub e segredos de CI carrega-se de forma invisível no momento da instalação. A Endor Labs documentou mais três vagas da mesma campanha entre novembro de 2025 e fevereiro de 2026, acrescentando 88 pacotes adicionais carregados através de cerca de 50 contas descartáveis.

Os registos bloquearam a maioria dos nomes, mas não todos

Há uma boa notícia na investigação. Os registos de pacotes tornaram-se melhores a bloquear os nomes que os modelos tendem a inventar. Normalizam nomes semelhantes, mantêm listas de proibição e vigiam os padrões que aparecem em muitas amostras geradas. Quando o estudo de 2026 verificou a sua lista de 127 nomes alucinados partilhados, a maioria já tinha sido reivindicada ou bloqueada por projetos legítimos e pelas defesas dos registos.

O problema é que "maioria" não é "todos". O mesmo estudo encontrou 53 nomes ainda disponíveis para registo depois de aplicadas as proteções. Um único nome registável em que vários modelos de fronteira concordam é suficiente para construir um ataque em torno dele, porque o atacante só precisa de adivinhar o modelo, não o programador. Os operadores dos registos fecharam a maior parte da porta; a lacuna restante é estreita, mas está aberta.

O mesmo padrão já se espalhou para além dos gestores de pacotes. Os investigadores de segurança documentaram atacantes a registar domínios que os modelos alucinam, além de repositórios e skills que os agentes provavelmente vão inventar. O mecanismo é idêntico em cada caso: um modelo prevê um nome plausível e um sistema construído para confiar nessa previsão age em conformidade. Cada nova superfície que um agente consegue alcançar torna-se mais um lugar onde plantar um nome que o agente vai procurar.

Porque é que os agentes pioram isto

Um programador humano pode notar um nome de pacote suspeito. Um agente não. Os agentes instalam dependências de forma autónoma, muitas vezes sem que um humano leia o comando primeiro. Os investigadores demonstraram técnicas de injeção de prompt que enganam os agentes para pedirem nomes de pacotes controlados pelo atacante, com taxas de sucesso reportadas de até 100% em ferramentas como Cursor, Windsurf e GitHub Copilot.

Foi essa combinação que mudou o perfil de risco. A alucinação fornece o nome. O agente fornece a execução. O atacante só tem de esperar que os dois se encontrem.

O problema das fugas é o mesmo problema

Um relatório relacionado da empresa Glow descobriu agentes a expor mais de 13.000 imagens internas no GitHub, provenientes de mais de 300 organizações. O mecanismo é banal: os agentes e os seus utilizadores colocam capturas de ecrã, diagramas e documentos em repositórios públicos, por vezes sem perceber que "público" significa pesquisável e permanente. As mesmas ferramentas que tornam os programadores mais rápidos também facilitam mover material interno para onde ele não devia ir.

Ambos os problemas partilham uma causa raiz. Os agentes agem à velocidade da máquina com base em instruções que podem estar erradas (um nome alucinado) ou ser sensíveis (uma captura de ecrã interna). O ponto de controlo humano que costumava estar entre a intenção e a ação é exatamente o que o agente remove.

O que fazer na prática

As defesas não são complicadas, o que é uma boa notícia dada a rapidez com que a ameaça avançou.

Trate cada comando de instalação produzido por um agente como entrada não confiável. Verifique se o pacote existe antes de o instalar. Verifique a idade que tem; um nome alucinado que já foi registado será recente. Verifique se o publicador tem histórico. Para o npm e o PyPI, uma rápida consulta de metadados responde às três perguntas em segundos.

Exija aprovação humana antes de um agente adicionar uma dependência. Esta é a alteração de maior valor, porque deteta de uma só vez os nomes alucinados, os registos maliciosos e os pedidos injetados por prompt. Abranda um pouco o agente e fecha o maior buraco.

Mantenha o alcance do agente reduzido. Um agente de programação precisa de acesso ao repositório; raramente precisa de credenciais de produção e não deve ter um gestor de pacotes apontado para um registo privado sem verificação. Ferramentas como Socket e Snyk podem automatizar a consulta ao registo dentro do IDE ou do pipeline de CI, o que vale o custo quando uma equipa usa agentes em muitos repositórios.

A parte incómoda é que nada disto é um bug que se corrige com um patch. A alucinação está incorporada na forma como estes modelos preveem texto: geram o próximo nome plausível, não um nome verificado. A solução tem de viver no fluxo de trabalho em torno do modelo, e é um processo que a maioria das equipas pode começar esta semana.