O que é o slopsquatting? O novo ataque HalluSquatting aos agentes de código de IA

O que é o slopsquatting?

O slopsquatting é a prática de registar um nome de pacote de software que não existe mas que um grande modelo de linguagem tem probabilidade de alucinar, de modo que um programador ou um agente de IA instale o pacote do atacante acreditando que é legítimo. O termo foi cunhado por Seth Larson, Security Developer-in-Residence na Python Software Foundation, em abril de 2025, como uma fusão de "AI slop" e "typosquatting".

Há duas ideias por baixo dele, e ajuda mantê-las separadas. A alucinação de pacotes (package hallucination) é o comportamento do modelo: um LLM, ao qual se pede que escreva código, referencia um alvo de instalação que nunca foi publicado. O slopsquatting é o ataque que transforma esse comportamento num mecanismo de entrega, ao reclamar primeiro o nome alucinado. A alucinação é a vulnerabilidade; o slopsquatting é o exploit.

“

Um humano que lê "pip install reqwest-py" talvez pare e verifique. Um agente corre o comando. No momento em que um nome de pacote passa de uma sugestão que uma pessoa escreve para uma ação que um agente executa, o último ponto de controlo humano desaparece.

Slopsquatting vs typosquatting: qual é a diferença?

Ambos são ataques de confusão de nomes na cadeia de fornecimento de software, mas exploram erros diferentes e, sobretudo, iludem defesas diferentes.

A diferença que sustenta tudo é a terceira linha. As defesas contra typosquatting partem do princípio de que o nome malicioso se parece com um real, por isso sinalizam pacotes dentro de uma pequena distância de edição de bibliotecas populares. Um nome alucinado não é uma grafia errada de coisa nenhuma. A análise da Socket a nomes alucinados concluiu que quase metade era altamente dissemelhante de qualquer pacote real, fabricada mas verosímil no contexto, que é exatamente por que a deteção de sósias passa mesmo ao lado deles.

Como funciona, na prática, um ataque de slopsquatting?

O ataque tem quatro passos, e a parte incómoda é que o atacante não precisa de adivinhar. O modelo diz-lhe o que registar.

O que torna o segundo passo explorável é que as alucinações não são ruído aleatório. No maior estudo até à data, os investigadores voltaram a correr o mesmo prompt dez vezes e concluíram que 43% dos nomes de pacotes alucinados reapareceram nas dez execuções, e 58% reapareceram mais do que uma vez. O modelo não inventa um nome falso diferente de cada vez; gravita para os mesmos. Um atacante consegue cultivar estes nomes em massa, registar os mais recorrentes, e esperar. Como os agentes em modos autónomos ou "yolo" instalam e executam sem confirmação, o hook de post-install do payload dispara no instante em que o pacote aterra, antes de existir uma pull request para rever.

Quão comuns são os pacotes alucinados?

Comuns o suficiente para serem um canal de distribuição e não um caso extremo. A medição definitiva é o estudo USENIX Security 2025 "We Have a Package for You!" da Universidade do Texas em San Antonio e do Virginia Tech, que analisou 2,23 milhões de amostras de código geradas por 16 modelos em Python e JavaScript.

A taxa não é uniforme. Os modelos de código aberto alucinaram pacotes em 21,7% das amostras contra 5,2% dos modelos comerciais, cerca de uma diferença de quatro vezes, e alguns modelos especializados em código inventaram um pacote em mais de um terço das suas saídas. Duas forças empurram então o risco para cima ao longo do tempo, e não para baixo: as equipas deixam cada vez mais os agentes escrever e instalar dependências sem supervisão, e os mesmos modelos continuam a sugerir os mesmos nomes fabricados a toda a gente que pergunta.

O slopsquatting já aconteceu no mundo real?

Sim, e a prova é anterior ao nome. No final de 2023, o investigador de segurança Bar Lanyado, da Lasso Security, reparou que vários modelos alucinavam repetidamente um pacote Python chamado huggingface-cli. Como prova de conceito inofensiva, publicou um pacote vazio sob esse nome. Em três meses tinha sido descarregado mais de 30 000 vezes e, como noticiou o The Register, uma grande empresa (a Alibaba) referenciava o comando de instalação no README de um dos seus próprios repositórios de investigação. O pacote era benigno. Um agente malicioso a observar a mesma alucinação não o seria.

A reviravolta de 2026 é que os agentes de IA passaram a espalhar estes nomes por si. A nota de investigação de abril de 2026 sobre slopsquatting da Cloud Security Alliance documenta como os comandos de instalação alucinados se propagam através de ficheiros de "agent skill" copiados e colados. Num caso de janeiro de 2026, um pacote npm fabricado (um nome que um modelo produziu ao fundir duas ferramentas reais) já era referenciado por 237 repositórios do GitHub antes de alguém o sinalizar, semeado em grande parte por um único commit que adicionou dezenas de ficheiros de skill gerados por LLM. A alucinação não ficou numa janela de chat; foi commitada, partilhada, e reexecutada por cada agente que leu a skill.

O que é o ataque HalluSquatting (julho de 2026)?

Durante quase toda a curta história do slopsquatting, o atacante era oportunista: registar quaisquer nomes que o modelo por acaso favorecesse, e depois esperar. Um artigo publicado a 8 de julho de 2026, "Beware of Agentic Botnets", de Spira, Cohen, Feldman, Bitton, Wool e Nassi (Universidade de Tel Aviv, Technion e Intuit), elimina a espera. Demonstra um gatilho adversarial universal e transferível que faz os agentes alucinar a pedido um recurso específico escolhido pelo atacante, em vez de torcer para que calhem num que o atacante já possui.

O mecanismo encadeia duas falhas que as secções anteriores descrevem. Primeiro, o gatilho orienta o agente a ir buscar um recurso (um repositório, uma skill, um pacote) sob um nome que o atacante controla. Segundo, uma injeção de prompt indireta escondida dentro desse recurso obtido executa quando o terminal do agente o corre, conseguindo execução remota de ferramentas e instalando malware de botnet auto-propagável. Os investigadores enquadram o resultado como um ataque não direcionado e escalável: um gatilho adversarial, sem configuração por vítima, malware que se espalha de um agente comprometido para o seguinte.

Por que razão um scanner não o consegue apanhar?

Porque os dois controlos em que a maioria das equipas confia, ou olham para o sítio errado, ou chegam demasiado tarde.

Leia a coluna da direita e emerge um único tema. Cada um destes controlos atua sobre o pacote depois de já estar em disco, ou procura uma semelhança que um nome fabricado não tem. O script de instalação de uma dependência maliciosa corre no momento da instalação, que para um agente autónomo é segundos depois de o modelo ter inventado o nome, e muito antes de qualquer scanner, revisor ou feed de CVE dar a sua opinião. O único lugar para o travar é antes de o comando de instalação executar.

Como prevenir o slopsquatting

Nenhuma destas é exótica. A disciplina está em aplicá-las a agentes que se movem mais depressa do que os humanos que os supervisionam.

1. Desligue a instalação automática às cegas. Não corra agentes em modos totalmente autónomos de "instalar e executar" contra credenciais reais. Exija aprovação explícita para qualquer nova dependência, de modo que um nome fabricado tenha de passar por um olhar humano.

2. Verifique que um pacote existe e é real antes de o adicionar. "Instalou" não é prova de legitimidade; o atacante garantiu que instalaria. Confirme que o pacote tem um histórico genuíno: idade, trajetória de downloads, um repositório de origem real, mantenedores com nome. Um pacote registado na semana passada que um modelo jura ser padrão é exatamente a forma deste ataque.

3. Fixe as versões e faça commit de lockfiles com hashes de integridade. Um lockfile com hashes significa que uma versão trocada ou recém-envenenada não se pode substituir em silêncio, e torna uma nova dependência visível como uma alteração revisível em vez de uma introdução transitiva invisível.

4. Restrinja de onde os pacotes podem vir. Use um mirror interno, um registo privado, ou uma lista de permitidos, de modo que o agente só possa instalar de fontes validadas. Se um nome alucinado não estiver no mirror, a instalação falha em modo fechado em vez de recorrer ao registo público.

5. Corra análise de composição de software, como rede de segurança. Vale a pena correr SCA em cada nova dependência, mas trate-a como a última rede, não a primeira. Apanha pacotes e versões reconhecidamente maus; não apanha um pacote malicioso de dia zero no dia em que é registado.

6. Reveja especificamente as novas dependências. Faça de "esta alteração adicionou uma dependência?" um passo de revisão explícito. Uma adição de uma linha ao package.json ou ao requirements.txt merece mais escrutínio do que cem linhas de lógica de negócio, porque importa o código de outra pessoa com os seus privilégios.

7. Isole o trabalho não confiável do agente. Quando um agente corre contra um repositório desconhecido ou conteúdo de terceiros, dê-lhe um contentor sem segredos do host e sem caminho para produção. Os scripts de instalação correm de imediato, por isso um agente orientado não deve ter nada de valioso ao alcance quando um deles disparar.

8. Trate os pacotes sugeridos pelo agente como input não confiável. A confiança da sugestão não é prova. Um nome que o modelo apresenta como óbvio é precisamente o nome que um atacante já verificou que o modelo gosta.

Onde a prevenção tem de viver: imposição no momento do agente

Percorra de novo essa lista e os controlos eficazes partilham uma propriedade: atuam antes de o comando de instalação correr. O scanner que lê um diff, o feed de SCA, a base de dados de CVE, chegam todos depois de o agente já ter ido buscar e executado o pacote. À cadência do agente, isso é demasiado tarde. O lugar para impor "não instales um pacote que não consegues verificar" é dentro do ciclo do agente, no momento em que o agente estende a mão para o comando de instalação.

É essa a camada que o VibeDefend acrescenta. É uma CLI npm gratuita que instala em cerca de cinco segundos e liga os seus agentes de código de IA (Claude Code, OpenAI Codex, Cursor, Windsurf e VS Code Copilot) a uma governação que corre enquanto eles trabalham, e não depois.

Duas das quatro camadas mapeiam diretamente para este ataque. O Action Guard interceta a ação arriscada antes de ela disparar: a instalação de um pacote não verificado, acabado de criar, ou ausente da sua lista de permitidos, é avisada ou bloqueada, com a interceção no registo de auditoria, de modo que a dependência fabricada nunca chega ao passo de instalação. As Regras de Segurança carregam a própria disciplina no contexto do agente antes de ele escrever, de modo que "verificar que uma dependência existe e é de confiança antes de a adicionar" é uma regra que o agente lê no momento do prompt em vez de um item de checklist que ninguém aplicou. A par delas, as Live Findings mantêm ao vivo no contexto do agente cada resultado dos scanners da CybeDefend (SAST com alcançabilidade, SCA, segredos, IaC e CI/CD), de modo que um problema de dependência é triado no ciclo em vez de aparecer dias depois.

E a SCA da CybeDefend atualiza a sua inteligência de vulnerabilidades de forma contínua, uma recolha nova a cada quinze minutos, aproximadamente, por isso, no instante em que um pacote é divulgado como malicioso, ele aparece no agente em minutos e não apenas na varredura noturna seguinte, e cada dependência que o agente puxa é verificada dentro do ciclo. As duas camadas fecham as brechas uma da outra: o Action Guard trava a instalação de um pacote acabado de criar que ainda ninguém sinalizou, e a SCA, atualizada em contínuo, apanha os que só mais tarde se revelam maliciosos.

Crucialmente, nada do seu código atravessa a rede. As decisões acontecem localmente, ao lado do agente; apenas metadados de governação estruturados (a regra que disparou, o caminho do ficheiro, a severidade, um timestamp) chegam ao backend, e os tenants da EU e dos US são fisicamente separados. Isto não substitui os lockfiles, as listas de permitidos, e a revisão humana. É a camada que os torna aplicáveis à velocidade a que um agente de facto trabalha, de modo que a instalação de um pacote que nunca foi real é travada antes de acontecer, em vez de investigada depois.

A CybeDefend é a camada de AppSec no momento do agente construída exatamente para isto. Liga cada agente de código de IA na sua máquina às suas regras de negócio, aos seus frameworks de segurança (OWASP, SOC 2, GDPR, ISO 27001), a um Action Guard que bloqueia instalações inseguras ou não verificadas antes de correrem, e à análise, atualizada em contínuo, de cada dependência e de cada linha que o agente escreve. O slopsquatting só funciona na brecha entre um modelo inventar um nome e um humano reparar. A CybeDefend fecha essa brecha, dentro do ciclo, antes de a PR sequer ser aberta.

Perguntas frequentes

O que é o slopsquatting?

O slopsquatting é um ataque à cadeia de fornecimento de software que regista um nome de pacote que um modelo de IA tem probabilidade de alucinar, de modo que programadores e agentes de código de IA instalem o pacote malicioso do atacante acreditando que é uma dependência real. O termo, cunhado por Seth Larson, da Python Software Foundation, em abril de 2025, combina "AI slop" e "typosquatting". Funciona porque os grandes modelos de linguagem inventam nomes de pacotes plausíveis que não existem, e inventam os mesmos de forma consistente, dando aos atacantes uma lista previsível de nomes para reclamar.

Qual é a diferença entre slopsquatting e typosquatting?

O typosquatting explora erros de digitação humanos ao registar nomes que se parecem muito com pacotes reais, por isso pode ser detetado ao medir a distância de strings em relação a bibliotecas populares. O slopsquatting explora a alucinação de IA ao registar nomes inteiramente fabricados que um modelo inventa, que não são grafias erradas de nenhum pacote real e, por conseguinte, iludem a deteção de sósias. Em resumo, o typosquatting aposta em os seus dedos escorregarem; o slopsquatting aposta em o seu assistente de IA inventar uma dependência e instalá-la por si.

O que é o ataque HalluSquatting?

O HalluSquatting é uma escalada de 2026 do slopsquatting descrita no artigo "Beware of Agentic Botnets" (arXiv, 8 de julho de 2026). Em vez de esperar que um modelo calhe num nome que o atacante já possui, usa um gatilho adversarial universal e transferível para fazer os agentes de IA alucinar a pedido um recurso específico escolhido pelo atacante, encadeando-o depois com injeção de prompt indireta para conseguir execução remota de código e espalhar malware de botnet. Os investigadores reportaram taxas de recursos alucinados até 85% para clonagem de repositórios e 100% para instalação de skills, ao longo de nove assistentes incluindo Cursor, Windsurf, Copilot, Cline e Gemini CLI.

Quão comuns são as alucinações de pacotes por IA?

Muito comuns. Um estudo USENIX Security 2025 de 2,23 milhões de amostras de código geradas por IA concluiu que 19,7% referenciavam pelo menos um pacote alucinado, catalogou 205 474 nomes fabricados únicos, e mostrou que as alucinações são repetíveis: 43% delas repetiram-se ao longo das dez repetições do mesmo prompt. Os modelos de código aberto foram piores (21,7%) do que os comerciais (5,2%). A repetibilidade é o que torna o problema explorável, porque os atacantes conseguem prever e pré-registar os nomes que um modelo favorece.

Um scanner de SCA ou a deteção de typosquatting conseguem apanhar o slopsquatting?

Não de forma fiável, e por duas razões diferentes. A deteção de typosquatting procura nomes dentro de uma pequena distância de edição de pacotes reais, mas um nome alucinado é fabricado e não um quase-acerto, por isso não está próximo de nada que o filtro vigie. A análise de composição de software corre depois de um pacote ser instalado e procura versões com vulnerabilidades conhecidas, mas um pacote malicioso registado de fresco ainda não tem CVE, e o seu script de instalação já executou quando a SCA olha. Vale a pena correr ambas como redes de segurança; nenhuma trava a própria instalação.

Como impeço o meu agente de código de IA de instalar pacotes alucinados?

Não deixe os agentes instalar dependências sem supervisão, verifique que qualquer novo pacote existe de facto e tem um histórico real antes de o adicionar, restrinja as instalações a um registo privado ou lista de permitidos, e faça commit de lockfiles com hashes de integridade para que as novas dependências sejam visíveis e revisíveis. Como estas verificações só ajudam se algo as impuser antes de o comando de instalação correr, a correção duradoura é a imposição no momento do agente: um controlo como o VibeDefend que interceta a instalação de um pacote não verificado ou inexistente dentro do ciclo do agente, em vez de um scanner que lê o estrago depois.