O problema em uma frase
Da próxima vez um O assistente de IA recomenda um pacote para instalar.Você vai mesmo verificar se esse pacote existe? A maioria dos desenvolvedores não faz isso. Essa lacuna entre a sugestão e a verificação é exatamente onde os ataques de slopsquatting começam, e é por isso que entender tanto a evolução do slopsquatting quanto a prevenção prática desse tipo de ataque se tornou uma prioridade real para as equipes de segurança de aplicativos (AppSec) e DevSecOps.
O que é um ataque de agachamento desleixado?
Um ataque de agachamento desleixado é uma variante de typosquatting (a prática de registrar um nome de domínio ou pacote que imita um legítimo por meio de um erro ortográfico comum, como) solicitações em vez de pedidosExistem dois tipos de ataques: o typosquatting (que explora erros de digitação, como o erro de digitação do próprio usuário) e o slopsquatting (que explora erros de digitação humanos). Já o slopsquatting explora os erros cometidos por grandes modelos de linguagem: um modelo de linguagem "alucina" um nome de pacote que soa perfeitamente legítimo, mas não existe em nenhum registro público, e um atacante o registra primeiro, antes de qualquer pessoa com boas intenções.
O mecanismo por trás de um ataque típico de agachamento desleixado é simples, e essa simplicidade é exatamente o que o torna eficaz:
- Um desenvolvedor pede a um assistente de IA para ajudá-lo a resolver um problema de programação.
- O modelo gera uma solução que importa ou recomenda a instalação de um pacote que nunca existiu.
- Um atacante que percebe que vários modelos repetem o mesmo nome alucinado registra esse pacote no npm, PyPI ou outro registro público, com código malicioso em seu interior. É nesse momento que a alucinação se transforma em um ataque real de slopsquatting.
- O próximo desenvolvedor que receber a mesma sugestão e não a verificar, instalará o pacote, agora real, que é uma porta dos fundos para o seu ambiente.
O termo “slopsquatting” foi cunhado por Seth Larson, desenvolvedor de segurança residente na Python Software Foundation, e popularizado por Andrew Nesbitt, para descrever exatamente esse padrão: uma “alucinação de pacote” transformada em um vetor de ataque.
Evolução do slopsquatting: como uma curiosidade de pesquisa se transformou em uma ameaça real.
O que é notável na evolução do slopsquatting não é apenas o conceito, mas a rapidez com que passou de uma observação de pesquisa para uma classe de ataque documentada e mensurável.
2023: O primeiro sinal de alerta. Pesquisador de segurança Bar Lanyado Percebi que vários mestres em direito (LLMs) recomendavam repetidamente um pacote chamado abraçandoface-cli, que não existe (o pacote real é instalado com pip install -U “huggingface_hub[cli]”Para demonstrar o risco, ele carregou uma versão vazia desse pacote em um registro público. Em três meses, o pacote recebeu mais de 30,000 downloads, sem nenhuma divulgação. O nome alucinado chegou a aparecer no arquivo README de um repositório ligado a uma pesquisa da Alibaba, mostrando desde cedo como esses nomes "falsos" podiam vazar para documentação real e preparar o terreno para os ataques de slopsquatting que se seguiriam.
2024: O risco passa de uma postagem de blog de um pesquisador para a cobertura da mídia especializada em tecnologia. Em março 2024, O registro A cobertura jornalística mostrou como modelos de IA estavam criando, com confiança, nomes de pacotes de software que os desenvolvedores baixavam, alguns deles potencialmente contaminados com malware. Essa cobertura importou menos pelo que revelou tecnicamente e mais pelo que sinalizou: o caso do embraceface-cli não era mais uma curiosidade isolada; era o primeiro indício de um padrão sério o suficiente para ser noticiado pela grande imprensa de tecnologia, antes mesmo do estudo acadêmico de larga escala que confirmaria a sua dimensão um ano depois.
2025: A primeira medição rigorosa e em larga escala do problema. O artigo “Temos um pacote para você! Uma análise abrangente das alucinações de pacotes por LLMs geradores de código” (Spracklen et al., apresentado no Simpósio de Segurança USENIX) testaram 16 modelos de geração de código, tanto comerciais (GPT-4, GPT-3.5) quanto de código aberto (CodeLlama, DeepSeek, WizardCoder, Mistral), em 576,000 amostras de código Python e JavaScript. As descobertas marcam um ponto crucial na evolução do slopsquatting, transformando-o de uma prática anedótica em dados concretos:
- 19.7% dos pacotes recomendados pelos modelos 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 modelos comerciais (5.2%).
- Em todos os modelos testados, os pesquisadores registraram mais de 205,000 nomes de pacotes alucinados exclusivos, um conjunto grande o suficiente para alimentar ataques contínuos de slopsquatting em vários ecossistemas.
Um detalhe crucial do estudo, e provavelmente a razão pela qual a evolução do slopsquatting acelerou em vez de desaparecer, é que os nomes alucinados não são aleatórios e não mudam a cada tentativa. Os mesmos modelos tendem a repetir os mesmos nomes inventados quando recebem instruções semelhantes, o que significa que um atacante não precisa adivinhar. Ele só precisa observar o comportamento do modelo, identificar os nomes que se repetem e registrá-los antes que um desenvolvedor real o faça. Uma análise subsequente dessa repetibilidade revelou que, quando os pesquisadores executaram instruções idênticas dez vezes cada, 43% dos nomes de pacotes alucinados apareceram em todas as execuções, evidenciando que a maioria das alucinações são artefatos repetíveis, e não ruídos isolados. Essa repetibilidade é o que transforma uma alucinação isolada em um ataque de slopsquatting escalável.
2026: De pacotes isolados a agentes autônomos. 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 desenvolvedor copiando e colando um comando sugerido de instalação do pip ou do npm. Em janeiro de 2026, o pesquisador de segurança Charlie Eriksen descobriu que agentes de codificação de IA já haviam disseminado instruções que faziam referência a um pacote npm fictício, react-codeshift (um nome que plausivelmente combina duas ferramentas reais, jscodeshift e react-codemod), em 237 repositórios, com agentes ainda tentando instalá-lo diariamente. Eriksen registrou o nome por conta própria, de forma preventiva, antes que um atacante pudesse usá-lo como arma. Separadamente, um pacote malicioso real chamado unused-imports, fictício no lugar do legítimo eslint-plugin-unused-imports, ainda registrava cerca de 233 downloads semanais no início de 2026, apesar de o npm tê-lo colocado sob bloqueio de segurança, um sinal de quanto tempo um ataque de slopsquatting pode continuar atraindo vítimas mesmo depois de ser sinalizado. Mais recentemente, em julho de 2026, pesquisadores descreveram uma técnica relacionada, apelidada de "HalluSquatting", que encadeia uma alucinação de IA com uma injeção de código, de modo que um agente de codificação de IA que busca um recurso alucinado em nome de um usuário possa ser sequestrado para executar código fornecido pelo atacante, estendendo a evolução do slopsquatting de um risco de instalação passiva para um vetor ativo de execução remota de código dentro de fluxos de trabalho de desenvolvimento de agentes.
Por que a "codificação de vibração" ampliou a superfície para ataques de slopsquatting
Os ataques de slopsquatting não teriam muita importância se o código gerado por IA fosse uma prática de 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 cada vez menos o código antes de executá-lo, alterou a superfície de ataque de software de duas maneiras concretas, e ambas estão acelerando a evolução do slopsquatting:
- O ponto de partida não é mais apenas o desenvolvedor. Antes, um ataque de typosquatting dependia de uma única pessoa cometer um erro de digitação. Agora, o erro pode se originar dentro do próprio modelo e se propagar para centenas de desenvolvedores diferentes que fazem perguntas semelhantes e recebem a mesma recomendação distorcida, multiplicando o alcance de um único ataque de typosquatting.
- A superfície de ataque deslocou-se mais para cima na cadeia. Não basta mais monitorar o código escrito por um humano. As equipes também 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 de forma autônoma, sem revisão humana direta. A segurança de aplicativos tradicional, criada para revisar repositórios e humanos, é fundamental. commitO sistema nunca foi projetado para observar essa nova interação entre desenvolvedor, IA e registro de pacotes, que é exatamente onde os ataques de slopsquatting agora se escondem.
Nada disso significa que a IA generativa seja inerentemente insegura. Significa que ela introduz um novo tipo de risco na cadeia de suprimentos que as ferramentas de segurança tradicionais não foram projetadas para detectar, e que exige os mesmos 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 depender da memória ou da vigilância de cada desenvolvedor. Essa automação é a base de qualquer estratégia real de prevenção de slopsquatting.
Prevenção do "slopsquatting": o que as equipes podem fazer hoje
A boa notícia é que a prevenção de slopsquatting não exige ferramentas exóticas. Requer a aplicação sistemática de práticas de higiene de dependências que já existem, mas que muitas equipes relaxam no momento em que uma IA confiável "sugere" o código. Uma abordagem eficaz para a prevenção de slopsquatting geralmente combina o seguinte:
- Verifique manualmente qualquer pacote novo antes de instalá-lo., especialmente quando vem de uma sugestão de um assistente de IA. Confirme se existe no registro oficial, quem o mantém, quando foi publicado e se o número de downloads parece real. Esse simples hábito é a forma mais barata de prevenção de slopsquatting disponível para qualquer equipe.
- Nunca assuma que o código gerado por IA seja seguro por padrão. Um trecho de código que "funciona" não significa que suas dependências sejam legítimas. A análise de dependências deve fazer parte da revisão de código, e não ser uma exceção.
- Utilize arquivos de bloqueio e verificação de hash. Para fixar versões exatas e impedir que uma atualização silenciosa substitua o pacote original por um diferente daquele que foi auditado inicialmente.
- Implemente a verificação de dependências que identifica padrões de risco além das CVEs conhecidas.Pacotes anômalos, nomes suspeitosamente semelhantes a pacotes existentes, novos mantenedores sem histórico ou scripts de instalação com comportamento incomum. Um pacote recém-publicado, com quase nenhum histórico, que imita de perto o nome de algo "quase" familiar, é exatamente o padrão por trás da maioria dos ataques de slopsquatting documentados até o momento.
- Trate os registros públicos com o mesmo ceticismo.cism como qualquer outra fonte externa não verificada. O fato de que instalação de pip or npm install O fato de não gerar um erro não é prova de legitimidade.
- Treinar equipes de desenvolvimento sobre o fato de que a codificação assistida por IA não elimina a responsabilidade de verificar o que está sendo instalado; ela apenas adiciona uma etapa que precisa ser incorporada ao fluxo de trabalho como parte de qualquer plano sério de prevenção de slopsquatting.
Nenhuma dessas medidas é nova em si. O que mudou foi a escala: quando uma sugestão de dependência não vem mais do Stack Overflow ou de um colega, mas de um modelo que pode repetir o mesmo erro alucinatório para milhares de desenvolvedores diferentes, a verificação manual, embora ainda necessária, deixa de ser suficiente por si só. É por isso que mais equipes estão automatizando essa camada de prevenção de slopsquatting em seus sistemas. Análise de composição de software (SCA) ferramentas, em vez de deixar isso a critério de cada desenvolvedor.
Isto é précisely por quê ASPM plataformas como Xygeni Integrar a detecção de dependências suspeitas, abrangendo typosquatting, confusão de dependências e pacotes maliciosos conhecidos, na mesma análise de dependências de código aberto e IA. pipelinePortanto, a prevenção de slopsquatting não depende de cada desenvolvedor se lembrar de verificá-la cada vez que um assistente de IA sugerir uma nova dependência.
Perguntas frequentes
Um ataque de "slopsquatting" é o mesmo que um ataque de "typosquatting"?
Não exatamente. Ambos envolvem o registro de um nome de pacote falso para enganar quem o instala, mas a origem do erro difere. O typosquatting explora erros de digitação humanos. Um ataque de slopsquatting explora nomes de pacotes inventados (alucinados) por modelos de IA, que um atacante registra antes mesmo de existirem legitimamente.
Um gerenciador de pacotes pode impedir automaticamente esse tipo de ataque?
Não completamente, e é exatamente por isso que a prevenção de slopsquatting não pode parar no nível do gerenciador de pacotes. Se um atacante registrar o pacote falso antes que um desenvolvedor tente instalá-lo, a instalação será concluída sem erros, pois o pacote realmente existe, mesmo sendo malicioso. Uma prevenção eficaz requer verificação adicional da origem e do comportamento do pacote.
Isso afeta apenas os modelos de código aberto?
Não. O estudo de Spracklen et al. encontrou alucinações em todos os modelos testados, incluindo os comerciais, embora em uma taxa significativamente menor (5.2% contra 21.7% para os modelos de código aberto avaliados). Nenhum modelo está completamente livre do problema, o que explica, em parte, por que a evolução do slopsquatting acompanha o crescimento da programação assistida por IA em geral.
Trata-se de um risco teórico ou já foi explorado?
O abraçandoface-cli O caso de um pacote vazio carregado por um pesquisador e baixado mais de 30,000 vezes em três meses sem qualquer promoção demonstra que o risco não é apenas teórico: basta que um nome inventado seja suficientemente consistente em diferentes solicitações para que alguém o transforme em um ataque real de slopsquatting.
