Um caso relatado esta semana pela imprensa especializada voltou a colocar em cima da mesa um risco que já deixou de ser teórico: um programador pediu a um agente de inteligência artificial que lhe recomendasse uma biblioteca para uma tarefa comum e recebeu de volta o nome de um pacote com aspeto perfeitamente legítimo — mas que era, afinal, uma invenção do modelo, já registada num repositório público com código malicioso. A instalação só não avançou porque a equipa tinha por hábito verificar manualmente o número de descarregamentos e o código-fonte de qualquer dependência sugerida por IA. O episódio é a face visível de um vetor de ataque à cadeia de fornecimento de software conhecido como slopsquatting, hoje já documentado em investigação académica revista por pares e em campanhas reais com mais de mil pacotes maliciosos no npm.
Resposta rápida: Os modelos de IA inventam nomes de pacotes que não existem e os atacantes registam esses nomes com malware lá dentro — é o chamado slopsquatting. Estudos apresentados na USENIX Security mediram taxas de alucinação de 5,2% em modelos comerciais e 21,7% em modelos abertos, e uma réplica de 2026 mostra que o problema encolheu mas não desapareceu. A ação recomendada é simples e imediata: nenhuma dependência sugerida por um agente de IA entra num projeto sem verificação humana do nome, do repositório oficial e do histórico de publicação, com instalações sem execução automática de scripts.
O quase-incidente: uma recomendação com aspeto de rotina
O relato foi partilhado por Sergiy Fitsak, responsável pela consultora de desenvolvimento de software Softjourn, na coluna «PWNED» de The Register. Segundo a descrição publicada, um engenheiro pediu a um agente de IA que recomendasse um pacote necessário para uma tarefa comum e o agente devolveu o nome de um pacote com aspeto legítimo, formatado como uma biblioteca familiar. A travagem veio do processo interno: a equipa afirma ter detetado o problema porque já tinha criado o hábito de verificar contagens de descarregamentos e rever o código-fonte no GitHub antes de instalar seja o que for recomendado por IA.
Convém sublinhar o que não é verificável: trata-se de um relato de primeira mão de uma empresa, sem análise forense pública, sem nome do pacote e sem conhecimento do payload exato. O valor jornalístico não está no caso individual, mas no padrão — esse, sim, está sobejamente documentado por investigação independente.
Slopsquatting: o erro deixou de ser dos seus dedos
O termo combina «AI slop» com «typosquatting» e é atribuído a Seth Larson, security developer-in-residence da Python Software Foundation. A mecânica é direta: um modelo de linguagem alucina um nome de pacote plausível que nunca existiu, um atacante regista esse nome exato no npm ou no PyPI e o programador — ou o agente autónomo — que copia o comando de instalação puxa o código do atacante diretamente para a compilação.
A diferença face ao typosquatting clássico é o que torna a defesa mais difícil. O typosquatting explora o erro humano — escrever lodahs em vez de lodash — enquanto o slopsquatting explora um erro do modelo: o nome alucinado não é uma variante ortográfica de nada, é uma invenção plausível, pelo que heurísticas de semelhança de nomes não o apanham. Do lado do repositório não há nada para inspecionar até o atacante registar o nome — e nessa altura parece um pacote novo como qualquer outro.
Os números: o que diz a investigação revista por pares
A medição de referência é o artigo «We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs», de Spracklen e colegas, apresentado no 34.º USENIX Security Symposium (2025). Sobre o conjunto de modelos de setembro de 2024, os autores geraram 576 000 amostras de código em 16 modelos e concluíram que 21,7% das gerações de modelos abertos e 5,2% das gerações de modelos comerciais referenciavam pacotes inexistentes, identificando 205 474 nomes alucinados únicos.
A melhoria dos modelos reduziu — mas não eliminou — a superfície de ataque. Uma réplica publicada em 2026 aplicou a mesma metodologia a cinco modelos de fronteira lançados entre outubro de 2025 e março de 2026 e, em 199 845 pares de prompts em Python e JavaScript validados contra as listas do PyPI e do npm, mediu taxas globais entre 4,62% e 6,10%, identificando ainda 127 nomes de pacotes inventados de forma idêntica por todos os cinco modelos avaliados. A conclusão dos autores é lapidar: o intervalo encolheu, a ameaça não; a 4–7%, o slopsquatting continua economicamente atrativo para o adversário.
Há ainda um detalhe que explica porque é que isto funciona à escala: as alucinações repetem-se. A análise da USENIX 2025 mostrou padrões previsíveis — 38% são conflações (a fusão de dois nomes reais), 13% são variantes tipográficas e 51% são fabricações puras. Um atacante não precisa de nenhuma técnica exótica: basta perguntar repetidamente, extrair os nomes gerados e verificar quais estão disponíveis no repositório.
De prova de conceito a campanhas industriais
O caso fundador continua a ser o do investigador Bar Lanyado com o nome huggingface-cli. O nome coincide com o comando da versão de linha de comandos do HuggingFace Hub, mas não é o nome do pacote — a instalação correta é pip install -U "huggingface_hub[cli]"; Lanyado publicou um pacote vazio com o nome alucinado e, em três meses, recebeu mais de 30 000 descarregamentos. A mesma investigação documentou que documentação pública tinha copiado o comando de instalação recomendado pela IA sem verificação aparente, amplificando a aparência de legitimidade do pacote.
Em 2026 os casos passaram a ser maliciosos e recorrentes. O pacote npm unused-imports é apontado como um dos exemplos mais claros: os modelos alucinam este nome em vez do legítimo eslint-plugin-unused-imports e, no início de fevereiro de 2026, o pacote malicioso ainda registava cerca de 233 descarregamentos semanais apesar de estar retido por motivos de segurança pelo npm. Outro caso, o react-codeshift, ilustra a propagação automatizada: um nome inexistente, nascido da conflação entre jscodeshift e react-codemod, que apareceu pela primeira vez num único commit com 47 «Agent Skills» geradas por LLM. O mesmo nome terá alastrado por 237 repositórios através de skills geradas por IA, com descarregamentos diários gerados não por humanos a copiar código, mas por agentes autónomos a executar os seus próprios resultados.
O salto de escala aconteceu este mês. Uma campanha publicou cerca de 800 pacotes maliciosos no npm com nomes de typosquatting gerados por IA, entregando um RAT e um infostealer multiplataforma (Windows, macOS e Linux); rastreada pela Sonatype como «Flooding Dropper», instrui os programadores a carregar o pacote com require(), contornando os hooks de ciclo de vida habituais, e o descarregador WEL1DROPPER identifica o sistema operativo e a arquitetura para obter o payload a partir de Cloudflare Workers ou, em alternativa, de registos DNS TXT em wel1[.]ru. A equipa da OpenSourceMalware, que documentou o caso, referiu ter contabilizado mais de mil pacotes maliciosos publicados em 72 horas, e associa-a, com base em tradecraft partilhado, à anterior campanha «Moika», com mais de 250 pacotes npm em abril e maio de 2026.
Cronologia do problema
| Data | Marco |
|---|---|
| 2023 | Investigador documenta a alucinação recorrente do nome huggingface-cli e regista-o como teste |
| Agosto 2025 | USENIX Security 2025: 576 000 amostras, 16 modelos, 205 474 nomes alucinados únicos |
| Janeiro/fevereiro 2026 | Casos react-codeshift e unused-imports documentados por investigadores |
| Março 2026 | ENISA publica a primeira Technical Advisory sobre uso seguro de gestores de pacotes (v1.1) |
| Abril/maio 2026 | Campanha «Moika»: mais de 250 pacotes npm maliciosos |
| Agosto 2026 | Campanha WEL1DROPPER/Flooding Dropper ultrapassa o milhar de pacotes no npm |
Indicadores e sinais de alerta a vigiar
| Tipo | Indicador |
|---|---|
| Domínio (campanha WEL1DROPPER) | wel1[.]ru — consultas DNS TXT para obtenção de payload |
| Infraestrutura | Registos de proxy para os hosts Cloudflare Workers associados à campanha |
| Comportamento (macOS) | Executável que se faz passar por runtime legítimo e LaunchAgent de persistência |
| Padrão de engenharia social | README que pede explicitamente para carregar o módulo com require() |
| Sinal de risco em dependências | Pacote recomendado por IA com poucos descarregamentos semanais e sem histórico |
Mitigação: o que fazer antes do próximo npm install
A ENISA publicou orientação específica sobre este terreno. A primeira Technical Advisory da agência sobre gestores de pacotes (março de 2026, v1.1) resultou de consulta pública com 15 contributos de partes interessadas, especialistas e comunidade de código aberto e organiza as práticas em quatro fases: selecionar pacotes, integrá-los nos projetos, monitorizar o seu estado de segurança e mitigar vulnerabilidades. Traduzido para o dia-a-dia de uma equipa que usa agentes de IA:
- Verificar sempre se o nome existe no repositório oficial do projeto e não apenas no npm/PyPI; desconfiar de nomes que «fazem sentido demais».
- Confirmar autoria, histórico de versões, ligação ao repositório de origem e volume de descarregamentos antes de adicionar a dependência.
- Desativar a execução automática de scripts de instalação (
--ignore-scriptsou equivalente) e fixar versões, evitando puxar pacotes acabados de publicar. - Não confiar em READMEs que instruem a carregar ou executar o módulo de forma «especial» — foi exatamente esse o truque da campanha WEL1DROPPER.
- Manter humano no circuito: revisão obrigatória de qualquer dependência nova introduzida por um agente, com registo da decisão.
- Executar agentes com privilégios mínimos, em ambientes isolados e sem acesso direto a credenciais de produção, tokens de CI/CD ou chaves de nuvem.
- Gerar e manter SBOM para saber, em minutos, se um pacote comprometido entrou em alguma compilação.
Vale ainda notar que os agentes podem ser induzidos ao erro por conteúdo externo, não só pela sua própria imaginação: uma campanha designada FakeGit usou milhares de repositórios GitHub disfarçados de AI Skills e servidores MCP para levar assistentes de código a recomendar malware, com o carregador SmartLoader a instalar o infostealer StealC. A lição defensiva é a mesma: o que o agente sugere é uma hipótese, não uma fonte de confiança.
Porque é que isto importa em Portugal
Para as PME portuguesas que hoje aceleram desenvolvimento com assistentes de IA, o risco não é abstrato: uma dependência maliciosa instalada num posto de trabalho de programação pode significar roubo de credenciais, acesso ao repositório de código e propagação para clientes. Para as entidades abrangidas pelo Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, que transpõe a NIS2), a segurança da cadeia de fornecimento e a gestão de riscos associados a fornecedores e componentes de software fazem parte das obrigações de gestão de risco, com deveres de notificação de incidentes junto do CNCS/CERT.PT. Uma compilação envenenada por um pacote alucinado é, em substância, um incidente de cadeia de fornecimento.
Há também o ângulo de produto: a partir de 11 de setembro de 2026, os fabricantes de software na UE passam a ter de reportar vulnerabilidades ativamente exploradas e incidentes que afetem os seus produtos, ao abrigo do Cyber Resilience Act. E, se o código comprometido tratar dados pessoais, aplica-se o RGPD, com os prazos de notificação à CNPD e, quando exigível, comunicação aos titulares. Em qualquer dos cenários, a diferença entre um susto e uma violação de dados foi, no caso relatado, aquilo que a equipa descreveu como alguns minutos extra de verificação manual.
Perguntas frequentes
O que é slopsquatting?
É um ataque à cadeia de fornecimento de software em que um atacante regista, no npm ou no PyPI, nomes de pacotes que os modelos de IA inventam com frequência. Quando outro programador ou agente segue a mesma sugestão, instala código malicioso em vez de uma biblioteca legítima.
Com que frequência os modelos inventam nomes de pacotes?
O estudo apresentado na USENIX Security 2025 mediu 5,2% em modelos comerciais e 21,7% em modelos abertos. Uma réplica de 2026 sobre cinco modelos de fronteira encontrou taxas entre 4,62% e 6,10%, ou seja, uma redução significativa mas sem eliminar o problema.
Desativar os scripts de instalação é suficiente para proteger a equipa?
Não. A campanha WEL1DROPPER mostrou que o código malicioso pode ser executado no momento em que o módulo é importado com require(), sem depender de hooks de preinstall ou postinstall. É preciso combinar verificação de nomes, revisão humana, isolamento do ambiente e monitorização de rede.
Que orientação oficial existe para equipas europeias?
A ENISA publicou em março de 2026 a sua primeira Technical Advisory sobre uso seguro de gestores de pacotes, com práticas para seleção, integração, monitorização e mitigação de dependências. Em Portugal, o CNCS/CERT.PT é o ponto de contacto para notificação de incidentes ao abrigo do Regime Jurídico da Cibersegurança.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela ENISA, pelos autores do estudo apresentado no USENIX Security Symposium 2025 e respetiva réplica de 2026, por investigadores de segurança de código aberto e pelo relato publicado por The Register.