O typosquatting, que consiste em registar uma versão com erro ortográfico de um pacote popular e esperar que um programador digite acidentalmente e instale o pacote errado, existe há uma década no npm. Não é nada de novo — o registo tem proteções contra isso.
Então surgiu a IA e mudou tudo novamente. Slopsquatting é a nova versão da typosquatting com IA. Em vez de apostar em erros de digitação humanos, os invasores apostam nas alucinações da IA, os nomes de pacotes que os LLMs recomendam com confiança, mas que na verdade não existem. Por um tempo, isso foi tratado como um risco teórico, mas não é mais o caso. As alucinações da IA estão na sala conosco, assim como os slopsquatters.
Neste artigo, vamos analisar como funciona o slopsquatting, o que os investigadores estão a descobrir atualmente e o que pode realmente fazer a esse respeito.
O que é slopsquatting?
Slopsquatting, também chamado de hallucination squatting, é o que acontece quando um invasor regista um nome de pacote que os modelos de IA tendem a alucinar e, em seguida, espera que os programadores o instalem por recomendação da IA. Os invasores de squatting contam com os assistentes de IA para sugerir com confiança nomes de pacotes que não existem e com os programadores para acreditar que se trata de um pacote real que eles solicitaram.
Quando um programador executa a instalação deste nome de pacote, obtém o pacote do invasor. O pacote geralmente executa algum script pós-instalação que rouba quaisquer credenciais que estejam no ambiente (chaves API, tokens de nuvem, tokens de autenticação npm) e as encaminha para o invasor.
Enquanto alguns pacotes incluem o ataque num script pós-instalação, pacotes mais sofisticados evitam colocar código malicioso no pacote, usando o suporte do npm para dependências baseadas em URL para obter uma carga útil de um servidor externo no momento da instalação. O pacote parece limpo para qualquer scanner estático ingênuo, pois não há código malicioso óbvio.
Digamos que você peça à sua IA para instalar um pacote de linter JavaScript. Ela oferece importações não utilizadas e pergunta se deseja instalá-lo (caso contrário, simplesmente ignora a pergunta). Parece ser o pacote que já utilizou antes, então instala-o.
Claude quer executar: npm install unused-imports
[y] Aceitar [n] Rejeitar [e] Editar [Esc] CancelarNo entanto, o pacote real é eslint-plugin-importações-não-utilizadasAcontece que, importações não utilizadas é um pacote malicioso e, surpresa! Acabou de instalar malware! (Na verdade, isto é um real pacote malicioso, aliás, e potencialmente um ataque intencional de slopsquatting. Pode procurar no Aikido .. O npm está a mantê-lo em espera por motivos de segurança neste momento).
Os LLMs realmente têm muitas alucinações com nomes de pacotes. Mackenzie Jackson, defensor de desenvolvedores da Aikido , descreveu uma alucinação que encontrou em um episódio do podcast Secure Disclosure. Ele pediu a uma IA para ajudá-lo a conectar seu projeto Node.js a um banco de dados OrientDB, uma combinação tecnicamente viável, mas incomum, sem uma solução de pacote óbvia. Em vez de admitir que estava perplexo, o modelo inventou nomes de pacotes. Mackenzie diz sobre o processo de pensamento da IA: «Não tenho nada para lhe oferecer, mas preciso de ter algo para lhe oferecer, então aqui está o que acho que os pacotes para isso se chamariam».
Qual é a diferença entre slopsquatting e typosquatting?
Typosquatting é quando um invasor regista um pacote malicioso com um nome semelhante a um pacote popular, de forma que o utilizador cometa um erro de digitação ao acessá-lo. Os invasores procuram um pacote com muitas descargas e um nome fácil de digitar errado, removem um hífen, trocam duas letras, adicionam um caractere extra e “ocupam” o pacote com o nome errado antes que alguém o faça. O typosquatting é uma prática comum no npm desde pelo menos 2017, quando um invasor publicou crossenv, um acampamento do popular cross-env pacote. O npm agora tem proteções contra isso, impedindo o registo de nomes de pacotes muito semelhantes aos já existentes.
Slopsquatting é typosquatting, mas em vez de apostar nos dedos gordos de um humano, os atacantes apostam que uma IA estará confiante em estar errada. (Sim, é assim que a IA é considerada confiável atualmente). A principal diferença entre slopsquatting e typosquatting que tivemos no passado é que as variantes parecem totalmente diferentes e, no primeiro caso, há um volume maior de nomes para os atacantes escolherem.
Por exemplo, 8,7% dos nomes de pacotes Python alucinados pela IA acabaram por ser pacotes JavaScript válidos. Neste caso, o modelo faz a ligação correta a algo real, mas no ecossistema errado. Um terreno fértil para os atacantes registarem nomes de pacotes de outros ecossistemas.
Pesquisadores da USENIX Security 2025 testaram 16 modelos em 576.000 amostras de código e descobriu que as alucinações seguem padrões previsíveis: 38% são combinações como express-mongoose, onde o modelo combina duas coisas reais, 13% são variantes de erros ortográficos e 51% são invenções puras. É um conjunto muito maior de nomes que podem ser usurpados do que o typosquatting jamais ofereceu e, ao contrário do typosquatting, nenhum desses novos nomes tem algo com que seja «semelhante» no sistema de proteção do npm.
Está a ocorrer ocupação ilegal neste momento?
Achamos que sim. Estamos a ver pacotes de malware cujos nomes são consistentes com o padrão de slopsquatting, mas não podemos provar quais são as intenções dos atacantes com esses nomes. Veja importações não utilizadas, o pacote malicioso confirmado de que falámos anteriormente. No início de fevereiro, ainda estava a ter 233 downloads por semana. Esses programadores estão a seguir recomendações de IA que ainda apontam para esse nome, têm-no em algum lugar na sua árvore de dependências e estão a reinstalá-lo, ou encontraram-no em documentos ou no Stack Overflow que não foram atualizados.
No entanto, os investigadores estão definitivamente a encontrar e a comprovar os primeiros precursores do slopsquatting na vida real. No início de 2024, Bar Lanyado, da Lasso Security, percebeu que os modelos de IA repetidamente alucinavam um pacote Python. chamado huggingface-cli. A ferramenta real é instalada de forma diferente, como pip install -U "huggingface_hub[cli]", mas os modelos continuavam a sugerir a versão mais curta e inexistente. Lanyado carregou um pacote vazio com esse nome no PyPI para ver o que aconteceria.
huggingface-cli obteve mais de 30.000 downloads autênticos em três meses. A Alibaba copiou e colou o comando de instalação alucinado no README de um dos seus repositórios públicos. O pacote era inofensivo, mas Lanyado provou que essa estratégia funciona. A Alibaba teve sorte que Lanyado descobriu isso antes que um invasor o fizesse.
Uma alucinação de pacote de IA que se espalhou por conta própria
Charlie Eriksen, Investigador de Segurança na Aikido encontrei algo ainda mais louco– um nome de pacote alucinado que se espalhou pela infraestrutura real de IA, com agentes reais a tentar executá-lo, que ninguém plantou deliberadamente. Em janeiro de 2026, Charlie afirmou que este pacote npm chamado react-codeshift. O pacote não era real, não tinha autor e definitivamente não tinha sido registrado antes. O nome é um clássico alucinação por fusão. Existem dois pacotes reais com nomes semelhantes, jscodeshift e react-codemod, que um LLM misturou para inventar o nome react-codeshift.
O pacote apareceu pela primeira vez num único commit de 47 habilidades de agente geradas por LLM. Podemos supor que uma IA foi solicitada a gerar um conjunto de instruções de agente de codificação e, ao fazê-lo, criou nomes de pacotes alucinados que seriam necessários para realizar essas tarefas. Nenhum humano revisou o resultado (ou, pelo menos, não o testou), então essa alucinação da IA foi imortalizada através do GitHub.
Quando Charlie o encontrou como parte de a sua investigação sobre encomendas não reclamadas, o nome desse pacote inexistente espalhou-se por 237 repositórios através de bifurcações e foi traduzido para japonês. Depois de Charlie o reivindicar, react-codeshift continuava a receber alguns downloads diários. Trata-se de agentes de IA que seguem instruções de competências e acionam instalações npx em ambientes reais. Se um invasor tivesse registado primeiro, poderia ter ocorrido um ataque slopsquatting maior que se espalhasse organicamente.
Como se proteger contra ataques de slopsquatting
Verifique a editora, não apenas o nome
A resposta óbvia é verificar os nomes dos pacotes antes de instalar, mas não é assim tão simples. O número de downloads não é um sinal fiável (vimos que pacotes maliciosos ainda têm downloads diários regulares). O que realmente importa é o editor: quem registou este pacote, quando, e isso corresponde ao que se esperaria de um mantenedor legítimo? Um pacote que afirma ser um eslint Um plugin sem informações sobre o mantenedor e com data de registo na última terça-feira é um sinal de alerta, independentemente do número de downloads.
Trate a instalação autónoma de pacotes como uma operação privilegiada
Se estiver a executar agentes de IA que podem instalar pacotes sem confirmação, Claude Code em modo de bypass, uma configuração de codificação agênica ou pipelines de CI com permissões npm amplas, a etapa de verificação que normalmente faria como humano desaparece. O agente simplesmente prosseguirá se tiver autoridade para isso. Esse é o modelo de ameaça em que o slopsquatting se baseia, portanto, defina essas permissões de acordo.
Analise toda a sua árvore de dependências
Alguns nomes de pacotes alucinados acabam por se tornar dependências aninhadas em vez de instalações diretas, o que significa que não aparecerão no seu package.json. O scanner análise de composição de software SCA) examina toda a sua árvore de dependências para detectar pacotes maliciosos ocultos e enterrados.
Use o SafeChain para proteção no nível do npm
Aikido é um wrapper de código aberto para npm, npx, fio, e pnpm que intercepta comandos de instalação de pacotes e os verifica em relação a Aikido Intel antes que qualquer coisa atinja a sua máquina.
Conclusão
Os nomes de pacotes não reivindicados sempre puderam ser reivindicados, mas agora temos IAs que nos fornecem com confiança nomes de pacotes falsos para instalar e agentes de IA que espalham os nomes pelos repositórios.
À medida que a codificação por vibração se torna a norma e mais agentes de IA com tema de lagosta começam a codificar sem humanos por perto (leia o nosso artigo sobre «Por que tentar proteger o OpenClaw é ridículo»), a janela para um humano detectar um nome de pacote inválido antes que ele seja executado continua a diminuir. Vimos que os nomes que os LLMs alucinam são consistentes e repetíveis, e os invasores estão a perceber isso.
Verifique as suas árvores de dependências. Verifique os editores. E utilize uma ferramenta que fica entre o seu gestor de pacotes e o registo e faz a verificação por si.
