TL, DR
Pacotes npm maliciosos não são eventos ocasionais. Trata-se de uma operação contínua de publicação, e a lista de casos confirmados é atualizada semanalmente. Ao longo de sete edições consecutivas do nosso Malicious Code Digest, agora na sua 87ª edição, a Xygeni confirmou 635 pacotes maliciosos, de 13 em uma semana tranquila a 206 em uma semana movimentada. A variação semanal é o ponto principal: trata-se de uma cadência, não de um incidente isolado.
- O problema está na cadência. Um pacote passou de zero para mais de 55 versões em uma semana. Outro cluster publicou quase 30 nomes de pacotes em menos de três horas. Uma auditoria semanal é uma unidade de tempo inadequada.
- Eles não chegam como CVEs. Um pacote malicioso não é uma falha em código legítimo, portanto não há aviso, pontuação ou, geralmente, qualquer identificador. Um programa orientado a vulnerabilidades é estruturalmente cego a isso.
- A remoção do dispositivo não é proteção. Os pacotes geralmente ficam ativos por minutos ou horas. Sua instalação ocorreu nesse período ou não.
- A detecção deve ocorrer na publicação e a aplicação na instalação. Qualquer coisa que aguarde uma assinatura, uma CVE ou uma verificação semanal chega depois da versão que a incluiu.
A lista existe. Isso não é o mesmo que estar sendo vigiado.
Não há mistério algum sobre pacotes npm maliciosos. Casos confirmados são publicados, nomeados e documentados todas as semanas, inclusive em Resumo de Código Malicioso do próprio Xygeni, que já ultrapassou a sua octogésima sétima edição.
A lacuna não está na informação, mas sim na atenção e na frequência. Uma lista atualizada semanalmente, lida mensalmente e com ações tomadas trimestralmente é uma lista que documenta o que já aconteceu com alguém.
Eis como foram as sete semanas, com base em nossas próprias conclusões confirmadas, e não em uma pesquisa com fornecedores.
O padrão que importa não são os totais. É a velocidade com que se atinge a cada semana.
A velocidade é o ataque completo
Três descobertas dessas semanas, cada uma uma maneira diferente de driblar a revisão.
- Inundação de versões. Um único pacote npm,
zevairouter, alcançou mais de 55 versões confirmadas em uma semana, juntamente com mais dez de um pacote complementar. No PyPI,bingo-aiProduziu quase 80 versões em aproximadamente 30 minutos. Nenhum processo de revisão manual opera nessa velocidade, nem mesmo uma tarefa noturna. - Clusters sincronizados. Dezessete pacotes imitando nomes de serviços internos do PayPal foram publicados em poucos minutos, todos na versão 28.0.0. Isso não é volume, é uma corrida: existe um número de versão inflado para superar o pacote interno que suas próprias equipes escreveram. O mesmo truque reapareceu semanas depois com
@umschool/platformPublicado em 999.0.0. - Persistência até a derrubada. A campanha de falsificação da marca Baileys está em andamento há semanas. Os nomes mudam, as versões aumentam e a republicação continua mesmo após a detecção. Um operador que trata a remoção de conteúdo como um custo inerente ao negócio, em vez de um motivo para interrompê-lo, é um operador que sua revisão trimestral jamais conseguirá alcançar.
E o tempo de permanência é curto propositalmente. Em um surto recente, os pacotes permaneceram ativos entre 17 minutos e 13 horas antes de serem removidos.
Leia isso como uma janela de exposição, e não como uma métrica de desempenho para o registro. Se uma compilação foi executada durante esse período, a remoção não alterou nada.
Por que seu programa de vulnerabilidade não detecta isso?
Este é o ponto estrutural, e é aquele que a maioria das equipes de segurança ainda não internalizou.
Uma vulnerabilidade é uma falha em um código escrito de boa fé. Um pacote malicioso é um artefato deliberado publicado por um atacante, geralmente sem identificador, sem aviso e com uma vida útil medida em horas. Todos os processos criados em torno da ingestão de CVEs, da classificação de gravidade e das janelas de aplicação de patches foram projetados para o primeiro caso e aplicados ao segundo por padrão.
A ausência de um identificador não é uma falha no sistema CVE. É a categoria funcionando conforme o esperado: ninguém registra um alerta contra um artefato cujo propósito era exclusivamente malicioso e, quando alguém finalmente poderia fazê-lo, o pacote já desapareceu. O que significa que a pergunta “Isso possui alguma CVE?A busca retorna a mesma resposta tanto para um pacote limpo quanto para um programa que rouba credenciais, publicado há uma hora.
O que as cargas úteis realmente fazem agora
A visão ingênua que se tem de pacotes npm maliciosos é a de um minerador de criptomoedas. A realidade atual é o roubo de credenciais direcionado a desenvolvedores e, cada vez mais, às credenciais de IA em suas máquinas.
O PhantomSync O cluster, composto por oito pacotes npm publicados sob uma única conta, funcionou exatamente como anunciado, ocultando um dropper que se autoexecutava aproximadamente 37 segundos após a importação, decodificava um payload disfarçado de teste falso, instalava persistência multiplataforma e executava um programa para roubar carteiras e segredos. Atrasar, disfarçar, persistir, exfiltrar.
Em uma escala maior, a onda CHAINDROP do Verme Shai-Hulud No início de agosto de 2026, o projeto atingiu mais de 400 pacotes e 1,700 versões, com um total de 1.3 bilhão de downloads mensais. Seu coletor de dados buscava mais de 300 padrões de credenciais, incluindo chaves OpenAI, Anthropic e Cursor. As máquinas de desenvolvedores se tornaram valiosas antes mesmo de seu lançamento.cisExigemente por causa das credenciais do modelo que possuem.
As convenções de nomenclatura seguiram o dinheiro. Clusters recentes se fazem passar por SDKs de criptomoedas e DeFi, módulos de pagamento, bibliotecas da API do WhatsApp, utilitários da AWS e, em um caso, um pacote abertamente identificado com o nome de uma ferramenta de ataque dark-LLM.
O que realmente impede pacotes npm maliciosos?
Quatro controles, na ordem em que dão resultado.
1. Detecção na publicação, não na divulgação. Alerta antecipado de malware da Xygeni Analisa pacotes recém-publicados no npm, PyPI, Maven e outros registros no momento em que aparecem, usando análise comportamental e de anomalias, em vez de esperar por uma assinatura ou um relatório. Esse é o único ponto na linha do tempo que está à frente da sua compilação.
2. Fiscalização no local da instalação. A detecção informa que um pacote é malicioso. Uma política que bloqueia a instalação é o que impede a execução do script de pós-instalação. Isso é ainda mais importante agora que os agentes instalam dependências sem a intervenção humana.
3. Arquivos de bloqueio e fixação de hash. Uso npm ci em CI em vez de npm installPortanto, a árvore de dependências exata no arquivo de bloqueio é o que é construído. Isso elimina a rota de substituição da qual dependem os typosquats e as versões infladas.
4. Resultados reunidos em um só lugar. As detecções de malware devem ter a mesma prioridade que as suas outras detecções. SCA e descobertas de código, não em um feed separado que alguém apenas folheia. Uma dependência maliciosa confirmada deve ter prioridade sobre uma CVE de gravidade média, e somente um modelo de risco compartilhado torna essa comparação possível.
Acompanhe a lista ou automatize-a.
Ninguém tem paciência para ler um registro de casamento toda semana. É para isso que serve a automação.
O Xygeni analisa pacotes recém-publicados no npm e em outros registros no momento da publicação, sinaliza malware confirmado antes que ele chegue a uma compilação e coloca a descoberta na mesma fila de prioridades que tudo o mais com que suas equipes já trabalham. Detecção de malware Está incluído no plano gratuito para desenvolvedores, o que não acontece na maioria dos planos gratuitos desta categoria.
Comece de graçaou leia Resumo de Código Malicioso desta semana em primeiro lugar.
Perguntas frequentes
O que são pacotes npm maliciosos?
Pacotes publicados no registro npm que são deliberadamente criados para causar danos: ladrões de credenciais e carteiras, backdoors, droppers e artefatos de confusão de dependências que se fazem passar por nomes de pacotes internos ou populares.
Quão comuns são os pacotes npm maliciosos?
Constantemente. Ao longo de sete edições recentes do nosso Malicious Code Digest, a Xygeni confirmou 635 pacotes maliciosos, variando de cerca de uma dúzia em uma semana tranquila a mais de 200 durante campanhas ativas. O npm é responsável pela grande maioria.
Por quanto tempo os pacotes npm maliciosos permanecem disponíveis?
Frequentemente, leva de minutos a horas. Esse intervalo de tempo é o que importa, porque uma compilação em execução dentro dele já está afetada, independentemente da rapidez com que o pacote seja removido posteriormente.
Pacotes npm maliciosos recebem CVEs?
Geralmente não. São artefatos publicados por atacantes, e não falhas em código legítimo, e as campanhas rastreadas de 2026 não receberam nenhuma atribuição de CVE durante a exploração ativa.
Como posso verificar se um pacote é malicioso antes de instalá-lo?
Use uma ferramenta que analise os pacotes no momento da publicação, em vez de uma que verifique uma lista de pacotes problemáticos conhecidos; verifique o editor e o histórico de versões; desconfie de números de versão excepcionalmente altos e contas recém-criadas; e aplique uma política no momento da instalação, em vez de depender de revisões.
O que é confusão de dependência?
Publicar um pacote com o mesmo nome de um pacote interno, geralmente em uma versão inflada, faz com que o resolvedor prefira a cópia do atacante. O cluster de nomes do PayPal na versão 28.0.0 é um exemplo clássico.
