Na próxima vez que um assistente de IA recomendar a instalação de um pacote, você vai verificar se ele realmente existe? A maioria dos desenvolvedores não faz isso. Essa lacuna entre a sugestão e a verificação é onde os ataques de slopsquatting começam e, em menos de três anos, a ameaça evoluiu de uma prova de conceito de um pesquisador para a execução remota de código dentro de agentes de codificação autônomos. Este artigo traça a evolução do slopsquatting e o que cada estágio significa para as equipes de segurança de aplicativos (AppSec) e DevSecOps.
É novo por aqui? Comece com o nosso guia introdutório sobre O que é slopsquatting e como se defender dele.Depois, volte para ver a linha do tempo.
Um ataque de agachamento desleixado em um parágrafo
Um ataque de agachamento desleixado Registra um pacote malicioso com um nome que os modelos de IA previsivelmente alucinam. Onde o typosquatting explora um erro de digitação humano. solicitações pela pedidosO slopsquatting explora o próprio modelo, inventando um nome plausível que não existe em nenhum registro, e então um atacante reivindica esse nome exato antes de qualquer pessoa legítima. O termo foi cunhado por Seth Larson, desenvolvedor de segurança residente na Python Software Foundation, e popularizado por Andrew Nesbitt. O que torna esse padrão digno de atenção é a rapidez com que amadureceu.
Evolução do agachamento desleixado
2023: o primeiro sinal de alerta
O pesquisador de segurança Bar Lanyado notou que vários LLMs continuavam recomendando um pacote chamado abraçandoface-cli, que não existe (a ferramenta real é instalada com pip install -U “huggingface_hub[cli]”Para demonstrar o risco, ele carregou um pacote vazio com esse nome alucinatório. Em três meses, o pacote foi baixado mais de 30,000 vezes, sem nenhuma divulgação, e o nome falso chegou a aparecer no arquivo README de um repositório vinculado a uma pesquisa de uma grande empresa de tecnologia. O pacote era inofensivo. A lição, porém, não era: basta que um nome alucinatório seja consistente o suficiente para que alguém o transforme em arma.
2024: da publicação no blog à cobertura da grande mídia
Em março de 2024, o The Register noticiou que modelos de IA estavam criando, com segurança, nomes de pacotes de software que os desenvolvedores baixavam, alguns potencialmente contaminados com malware. A reportagem importou menos pelo que revelou tecnicamente do que pelo que sinalizou: abraçandoface-cli Já não era uma curiosidade isolada, mas o primeiro sinal de um padrão suficientemente sério para que a imprensa especializada em tecnologia o noticiasse, antes do estudo em larga escala que confirmaria seu alcance um ano depois.
2025: a primeira medição rigorosa
O artigo "We Have a Package for You!" (Spracklen et al.), apresentado na conferência USENIX Security 2025, testou 16 modelos de geração de código, comerciais e de código aberto, em 576,000 exemplos de código Python e JavaScript. Com isso, transformou o conceito de "slopsquatting" (construção de código em código aberto) de uma mera anedota em dados concretos.
- 19.7% dos pacotes recomendados não existiam.
- Os modelos de código aberto causaram alucinações com muito mais frequência (21.7% em média) do que os comerciais (5.2%).
- Os piores infratores, CodeLlama 7B e 34B, apresentaram alucinações em mais de um terço de suas produções.
- Em todos os modelos, os pesquisadores registraram mais de 205,000 nomes alucinatórios únicos, um conjunto grande o suficiente para alimentar campanhas sustentadas em diversos ecossistemas.
O estudo também categorizou como as falsificações são formadas: 38% eram fusões que combinavam dois nomes de embalagens reais (exatamente o padrão que mais tarde produziu...). react-codeshift da jscodeshift e react-codemod), 13% eram variantes tipográficas de embalagens reais e 51% eram invenções plausíveis, mas completamente inventadas. Esse primeiro grupo é o mais importante para a defesa, porque um nome composto por duas ferramentas reais é o mais difícil de identificar à primeira vista.
A descoberta mais importante para os atacantes: as alucinações não são aleatórias e não mudam a cada tentativa. Quando os pesquisadores repetiram os mesmos comandos dez vezes cada, 43% dos nomes alucinados apareceram em todas as execuções e 58% se repetiram mais de uma vez. Um atacante não precisa adivinhar. Ele observa o comportamento do modelo, anota os nomes que se repetem e os registra primeiro. Essa repetibilidade é o que transforma uma alucinação isolada em um ataque escalável.
2026: de pacotes isolados a agentes autônomos
Este ano trouxe as evidências mais claras até agora de que o slopsquatting não se limita mais a um incorporador imobiliário copiando e colando uma sugestão. npm install.
Em janeiro de 2026, o pesquisador de segurança Charlie Eriksen encontrou um pacote npm alucinatório. react-codeshift, que as instruções do agente geradas por IA já haviam se espalhado por 237 repositórios através de forks, com agentes ainda tentando instalá-las diariamente. Elas se originaram em um único commit de arquivos de habilidades de agentes escritos por IA que nenhum humano havia revisado. Eriksen registrou o nome ele mesmo, defensivamente, antes que um invasor pudesse usá-lo como arma.
Separadamente, um pacote genuinamente malicioso chamado importações não utilizadas, alucinado no lugar do legítimo plugin-eslint-imports-não-utilizados, continuou a gerar instalações mesmo depois de o npm ter colocado o projeto sob bloqueio de segurança, mostrando por quanto tempo um ataque de slopsquatting pode continuar encontrando vítimas depois de ter sido sinalizado.
Em julho de 2026, pesquisadores descreveram uma técnica relacionada, apelidada de "HalluSquatting", que encadeia uma alucinação com uma injeção imediata: um agente de codificação de IA que busca um recurso alucinado em nome de um usuário pode ser sequestrado para executar código fornecido pelo atacante. Isso amplia a evolução do slopsquatting, transformando-o de um risco passivo de instalação em um vetor ativo de execução remota de código dentro de fluxos de trabalho de desenvolvimento de agentes.
Por que a “codificação intuitiva” expandiu a superfície de ataque?
O slopsquatting não teria muita importância se o código gerado por IA fosse um nicho. Mas não é. A ascensão de assistentes de codificação, agentes autônomos e fluxos de trabalho de "codificação intuitiva", em que os desenvolvedores revisam menos o código antes de executá-lo, alterou a superfície de ataque de duas maneiras concretas.
Primeiro, o ponto de entrada não é mais apenas o desenvolvedor. Um ataque de typosquatting dependia de um único erro de digitação. Agora, o erro se origina dentro do modelo e se propaga para centenas de desenvolvedores que fazem perguntas semelhantes e recebem a mesma recomendação distorcida.
Em segundo lugar, a superfície de ataque subiu na cadeia. Não basta mais observar o código escrito por um humano. As equipes precisam monitorar as dependências sugeridas por um assistente de IA, os servidores MCP aos quais ele se conecta e os agentes que instalam pacotes sem a intervenção humana. A segurança de aplicativos tradicional, criada para revisar repositórios e humanos, era baseada na análise de código. commitO sistema nunca foi projetado para observar essa interação entre desenvolvedor, IA e registro, que é exatamente onde o slopsquatting se esconde agora.
O que isso significa para a prevenção?
Nada disso torna a IA generativa inerentemente insegura. Ela introduz um risco na cadeia de suprimentos que as ferramentas tradicionais não foram projetadas para detectar, e exige os princípios de verificação que já aplicamos a qualquer dependência externa: não confie por padrão, verifique a fonte e automatize essa verificação em vez de confiar na memória de cada desenvolvedor. O guia completo de defesa está em nosso guia para Segurança da cadeia de suprimentos de IAMas, resumindo, a verificação manual, embora ainda necessária, deixa de ser escalável no momento em que um nome inventado pode alcançar milhares de desenvolvedores de uma só vez, ou quando um agente pode instalá-lo sem qualquer revisão humana.
Impeça que os pacotes alucinatórios sejam instalados por um agente.
Os casos de 2026 têm uma característica em comum: a instalação perigosa ocorre sem a intervenção humana. Essa é exatamente a lacuna. Xygeni Shield foi criado para. Shield é um agente leve no endpoint do desenvolvedor que bloqueia pacotes maliciosos no momento da instalação, usando Alerta antecipado de malware (MEW) veredictos que funcionam antes mesmo de qualquer assinatura existir. Quando um assistente de IA ou um agente autônomo tenta instalar um pacote alucinado e recém-registrado, Shield avalia o valor à medida que é obtido e o bloqueia, de modo que o script de instalação nunca é executado, independentemente de haver ou não um observador humano. Cada bloco flui para o mesmo Xygeni console como seu código, compilação e descobertas de tempo de execução, e Shield Funciona em conjunto com o seu EDR existente, em vez de competir com ele.
Comece gratuitamente. O plano Developer da Xygeni é €0: 10 repositórios, 200 verificações por mês, até 5 colaboradores, sem necessidade de cartão de crédito. Sign up with GitHub, GitLab ou Google e execute sua primeira verificação em menos de 10 minutos; Shield A proteção de endpoints estará disponível em breve no plano Developer.
Perguntas frequentes
Um gerenciador de pacotes pode impedir o slopsquatting por conta própria?
Não completamente. A detecção de colisões do npm bloqueia nomes muito semelhantes a pacotes existentes, o que ajuda a combater o typosquatting, mas um nome alucinado é uma string totalmente nova, sem colisões a serem detectadas. Se um atacante registrar o pacote alucinado antes que um desenvolvedor o instale, a instalação será concluída sem erros porque o pacote realmente existe. A prevenção requer a verificação da origem e do comportamento do pacote, e não apenas as verificações do próprio registro.
O que diferencia os casos de agentes de 2026 dos casos anteriores de ocupação irregular?
Os incidentes anteriores dependiam de um humano copiar e colar um comando de instalação sugerido. Nos casos de 2026, agentes autônomos instalaram ou tentaram instalar pacotes alucinados sem que nenhum humano revisasse a etapa, e a técnica HalluSquatting foi além, encadeando uma alucinação com uma injeção de prompt para obter execução remota de código dentro do fluxo de trabalho do agente.
