Slopsquatting: quando o seu assistente de IA instala um pacote que não existe

Peça ajuda a um assistente de código e muitas vezes ele vai sugerir uma biblioteca junto com o código. Na maioria das vezes a biblioteca é real. Às vezes não é: o modelo produz um nome que parece certo, segue as convenções de nomenclatura do ecossistema e simplesmente não existe no npm nem no PyPI. Se você executar o comando de instalação sem olhar, uma de duas coisas acontece. A instalação falha, o que é irritante, mas inofensivo. Ou alguém já publicou um pacote com exatamente esse nome, e você acabou de executar o código dessa pessoa.

O que é slopsquatting

Slopsquatting é o nome desse segundo caso: registrar nomes de pacotes que os modelos de IA tendem a inventar e esperar que as pessoas os instalem. O termo costuma ser atribuído a Seth Larson, security developer-in-residence da Python Software Foundation, e faz um trocadilho com typosquatting, em que atacantes registram grafias erradas de pacotes populares. A diferença é quem comete o erro. No typosquatting, uma pessoa digita errado. No slopsquatting, um modelo sugere com confiança o nome errado, e uma pessoa confia nele.

O risco não é hipotético. Em um experimento amplamente noticiado, um pesquisador percebeu que os modelos insistiam em recomendar um pacote chamado huggingface-cli, que não é a forma de instalar a ferramenta real da Hugging Face. Ele publicou um pacote vazio com esse nome para ver o que aconteceria, e o pacote foi baixado dezenas de milhares de vezes. O pacote era inofensivo. Um malicioso não teria sido.

Com que frequência os modelos inventam pacotes

O estudo mais completo até agora é “We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs”, apresentado na USENIX Security 2025. Os autores geraram 576.000 amostras de código em Python e JavaScript com 16 modelos populares e verificaram cada pacote a que o código fazia referência. Eles constataram que a proporção média de pacotes alucinados foi de pelo menos 5,2% para modelos comerciais e 21,7% para modelos open source, e reuniram 205.474 nomes únicos de pacotes que não existiam.

Dois detalhes do artigo importam mais do que os números principais. Primeiro, os nomes inventados costumam ser reproduzíveis: quando os autores reexecutaram dez vezes prompts que haviam produzido uma alucinação, 43% desses nomes voltaram em todas as vezes. Nomes previsíveis são exatamente o que um atacante precisa. Segundo, a maioria deles não é uma grafia quase igual à de pacotes reais, então uma verificação de erros de digitação não vai pegá-los. Apenas cerca de 13% ficavam a um ou dois caracteres de distância de um nome existente.

Os modelos melhoraram desde esses experimentos, e assistentes que consultam o registry antes de sugerir um pacote tornam o problema mais raro. Mais raro não é o mesmo que resolvido, especialmente em tarefas de nicho, para as quais o modelo viu poucos exemplos reais.

Por que o ataque é viável

Publicar no npm ou no PyPI é gratuito e leva minutos. O atacante não precisa comprometer nada; só precisa adivinhar os nomes que os modelos produzem e registrá-los primeiro. Os scripts de instalação fazem o resto: o npm executa scripts preinstall e postinstall por padrão, e um pacote Python pode executar código quando é construído ou importado. Uma única instalação no notebook de um desenvolvedor ou em um runner de CI pode expor chaves SSH, credenciais de nuvem e tokens em variáveis de ambiente.

Os agentes agravam isso. Quando um assistente pode executar npm install ou pip install por conta própria, pode não haver nenhum humano olhando o nome do pacote.

Verifique um pacote em um minuto

Antes de adicionar uma dependência que não foi você quem escolheu, consulte-a no registry:

# npm: does it exist, who publishes it, when was it first released?$ npm view some-package name version time.created repository.url # PyPI: same questions, from the JSON API$ curl -s https://pypi.org/pypi/some-package/json | jq '.info | {name, version, home_page, project_urls}'

Depois, faça algumas perguntas rápidas:

• Ele existe? Um 404 significa que o nome foi inventado. Não o crie, e não instale uma alternativa “parecida o bastante” sem verificá-la também.
• Ele é novinho? Um pacote publicado pela primeira vez nas últimas semanas, com uma única versão e sem histórico, merece uma segunda olhada, especialmente se o nome dele bater com o que o seu assistente sugeriu.
• Ele aponta para um projeto real? Um repositório vinculado com commits, issues e outros usuários é um bom sinal. Um repositório vazio ou ausente, não.
• É o pacote que a documentação manda instalar? A própria documentação da ferramenta real é a melhor fonte para o nome correto. huggingface-cli versus o comando de instalação documentado é um bom exemplo do porquê.

Hábitos que ajudam

• Use lockfiles e instale a partir deles no CI (npm ci, pip install -r com versões e hashes fixados), para que um nome novo não entre de fininho durante um build.
• Revise mudanças de dependências em pull requests com o mesmo cuidado que mudanças de código. Um diff que adiciona três pacotes merece três consultas.
• Peça ao seu assistente o link da página do pacote no registry ou da documentação oficial quando ele sugerir algo novo. É um jeito barato de revelar um nome inventado.
• Se o seu agente pode executar instalações por conta própria, dê a ele uma allowlist ou exija confirmação para novas dependências.
• Considere desativar os scripts de instalação por padrão (npm config set ignore-scripts true) e ativá-los apenas para os pacotes que precisam deles. Isso quebra alguns pacotes, então teste antes.

Automatize a parte chata

Consultas manuais funcionam para um pacote. Não escalam para um repositório com centenas de dependências, nem para imports enterrados em código que um assistente gerou na semana passada. Esse é um bom trabalho para ferramentas.

A suíte de riscos de código de IA do vetkit consulta as dependências e os imports dos seus manifestos em registries públicos como npm e PyPI. Ela sinaliza nomes que não existem, versões que nunca foram publicadas e pacotes lançados pela primeira vez nos últimos 30 dias. Apenas nomes e versões de pacotes são enviados aos registries, nunca o seu código-fonte, e pacotes de registries privados ou dos seus próprios workspaces não são consultados. O servidor MCP do vetkit também expõe uma verificação de pacotes, para que um assistente possa conferir um nome antes de instalar qualquer coisa.

Seja qual for a ferramenta, o princípio é o mesmo: um nome de pacote que veio de um modelo é uma afirmação, e afirmações são baratas de verificar antes de você executá-las.