Incidente de publicação automatizada de pacotes IndonesianFoods no ecossistema NPM ligado a golpe de mineração de recompensas em criptomoedas

“As descobertas da Amazon dão continuidade, na prática, à atividade do worm IndonesianFoods que nossa equipe analisou — um lembrete de que a automação baseada em IA torna trivial publicar centenas de milhares de pacotes inúteis ou arriscados em grande escala. Desenvolvedores devem recorrer a mecanismos automatizados para verificar a integridade das dependências e à análise baseada em comportamento, em vez de revisão manual: sinalizando pacotes com poucos downloads, conteúdo baseado em modelos reutilizados e eventos de publicação em massa repentinos antes que cheguem ao processo de build. E os operadores de registros também precisam evoluir — detectando proativamente carregamentos em massa, modelos com hashes reutilizados e anomalias nos indicadores de integridade dos metadados, para interromper essas campanhas na origem.”

- Manoj Nair, diretor de inovação, Snyk

Em resumo

Em novembro de 2025, pesquisadores de segurança identificaram um aumento em larga escala na publicação de pacotes no registro NPM, com estruturas e padrões de nomenclatura semelhantes. Embora os relatos iniciais especulassem que se tratava de um worm, é provável que essa atividade seja um vestígio de um script de automação há muito inativo, associado a um esquema de recompensas em criptomoedas. 

Observação: não foi confirmado nenhum exploit ativo em circulação, e os pacotes afetados atualmente representam risco mínimo. 

Parece que um desenvolvedor criou um script de spam e depois o publicou como parte do próprio spam; são vestígios de um script automatizado de publicação, originalmente associado a um projeto desatualizado de mineração de recompensas em criptomoedas. Há cinco pacotes distintos ao todo (copiados milhares de vezes com nomes ligeiramente diferentes), e a única funcionalidade maliciosa é a publicação contínua de pacotes. Cada pacote que contém o script de publicação tem, em média, apenas 18 downloads mensais. 

Ainda assim, o evento destaca a necessidade contínua de manter as dependências rigorosamente em ordem e adotar práticas confiáveis nos registros.

Componente e ecossistema envolvidos

O incidente envolve um grupo de pacotes NPM publicados em várias contas com nomes muito parecidos, usando modelos de código consistentes (geralmente baseados em Next.js) e pequenas diferenças estruturais entre versões e nomes (por exemplo, sufixos como -wekto, -riris e -z3n). Os pacotes parecem ter sido publicados em massa ao longo do tempo, provavelmente por meio de automação com scripts, e não instalados e explorados em sistemas ativos. Eles fazem referência a uma campanha antiga de recompensas em criptomoedas (tea.xyz), mas não apresentam execução maliciosa nem autopropagação confirmadas após a instalação.

Cronologia do incidente

• Final de 2023: alguns pacotes-base são publicados (por exemplo, vointea e voinzaril), inicialmente com código de aplicativo web aparentemente inofensivo.

• Pouco depois, começa a atividade de publicação em massa, envolvendo centenas ou milhares de pacotes derivados que usam modelos de código semelhantes com sufixos renomeados.

• Intervalo de alguns meses: a atividade é interrompida.

• Dois meses depois: ocorre outra publicação em massa de novas séries (os padrões de sufixos mudam).

• 11 de novembro de 2025: surgem discussões na comunidade sugerindo que até cerca de 44.000 pacotes podem estar envolvidos (embora o total real da publicação em massa possa ser menor).

• 12 de novembro de 2025: análises indicam que os pacotes são vestígios inofensivos de uma campanha antiga, e não malware ativo.

Pacotes NPM afetados

• É possível identificar cerca de cinco pacotes “raiz” distintos (vointea, voinzaril e variantes com os sufixos wekto, riris e z3n).

• Volume estimado de cópias: provavelmente na casa dos milhares (por exemplo, cerca de 4.000 a 5.000 pacotes), e não dezenas de milhares; os números mais altos incluem versões secundárias adicionais dentro dos pacotes.

• O volume médio de downloads desses pacotes é extremamente baixo (geralmente menos de 20 downloads por mês).

• Não foram relatados comprometimentos confirmados de dependências downstream nem observada nenhuma cadeia de exploração conhecida.

• Como a execução do código exige acionamento manual e não foi identificado nenhum payload remoto oculto, o risco para usuários comuns continua baixo.

Como aconteceu a campanha IndonesianFoods

Em vez de um worm clássico ou de um ataque por exploração remota, a atividade parece ser um processo automatizado de publicação: um script gerava e publicava variantes de um modelo básico de código de aplicativo web, provavelmente para fins de incentivo ou experimentação (por exemplo, associado a uma promoção de criptomoedas da “tea.xyz”).

A análise revelou que os pacotes não continham payloads nocivos; muitos incluíam apenas código padrão ou incompleto. O processo de publicação não tinha uma condição de encerramento automatizada e parece ter sido iniciado manualmente em dias específicos, em vez de se propagar de forma autônoma por sistemas infectados.

Resumo da atividade

• Uso de uma ou mais contas NPM com permissões elevadas de publicação.

• Um modelo de código reutilizado em centenas ou milhares de variantes.

• Pacotes com poucos downloads e uso mínimo

• Sem payloads complexos, furtivos ou polimórficos: apenas publicações ruidosas em massa.

Por que isso não foi sinalizado antes?

• Como os pacotes tinham poucos downloads e nenhum efeito evidente durante a execução, passaram despercebidos.

• Historicamente, as heurísticas dos registros se concentraram em exploits ou comportamentos maliciosos pós-instalação, e não apenas no volume de publicações.

• A campanha parece ter sido parcialmente abandonada; não foi observada nenhuma exploração ativa.

Estratégia de detecção e análise

O que desenvolvedores e organizações podem fazer

Desenvolvedores podem usar ferramentas como o Snyk Vulnerability Database para avaliar novas dependências com base em métricas de popularidade, manutenção, segurança e comunidade. 

Também é importante garantir que as análises automatizadas abranjam tanto a integridade das dependências quanto os riscos no código, com ferramentas como:

• Snyk Open Source (análise de composição de software) analisa bibliotecas de terceiros em busca de vulnerabilidades conhecidas e problemas de licença. 

• Snyk Code (testes estáticos de segurança de aplicações) analisa o código personalizado em busca de vulnerabilidades.

• Snyk Container e Snyk IaC analisam imagens de contêineres e configurações de infraestrutura como código, respectivamente.

Neste incidente, você pode sinalizar pacotes com pouquíssimos downloads ou conteúdo repetitivo em muitas versões. Também vale monitorar carregamentos repentinos em grande escala feitos por uma única conta ou a reutilização de modelos entre pacotes. Por fim, use heurísticas de metadados, como data da última publicação, histórico de versões, número de mantenedores e atividade da comunidade.

Como as equipes responsáveis pelos registros podem aprimorar o monitoramento

O monitoramento pode ser aprimorado acompanhando padrões de publicação em massa, especialmente o volume e o horário das publicações por conta. Também é importante implementar a detecção de picos no número de publicações, na rotatividade de versões e na reutilização de padrões de nomes. As equipes responsáveis pelos registros devem incluir verificações de reutilização de modelos, comparando hashes de arquivos entre diferentes pacotes. Por fim, devem avaliar desde o início métricas de “integridade” dos metadados, como downloads, estrelas no repositório e atividade dos mantenedores.

Mitigação e próximos passos

Para usuários finais e organizações:

1. Nenhuma ação corretiva imediata é necessária se você não tiver referenciado nem instalado nenhum dos pacotes suspeitos.

2. Revise seu grafo de dependências para identificar pacotes não utilizados ou de baixo risco e remover ou isolar as dependências usadas raramente.

3. Use o Snyk Advisor antes da instalação: verifique a integridade do pacote e os indicadores de risco antes de adicionar uma nova dependência.

4. Use o npq: npq é uma ferramenta de código aberto que impede a instalação desse tipo de pacote usando heurísticas como a contagem de downloads. 

5. Defina controles de política no seu CI/CD: por exemplo, bloqueie a inclusão de pacotes com downloads abaixo de um limite ou sem commits recentes.

Considerações finais

Embora a publicação desses pacotes no registro NPM tenha gerado manchetes sobre um “worm” ou um ataque à cadeia de suprimentos, nossa investigação confirma que não se trata de um surto ativo de malware, mas de um vestígio de automação passada associada a uma campanha de criptomoedas. O risco imediato para a maioria dos usuários é baixo. 

Ainda assim, o incidente serve de alerta oportuno: até pacotes aparentemente inofensivos podem introduzir riscos à cadeia de suprimentos quando não são gerenciados, são mal mantidos ou passam despercebidos. Usar ferramentas como Snyk Advisor e Snyk for JavaScript, aplicar políticas robustas para dependências e manter práticas rigorosas de monitoramento dos registros ajuda a preservar a integridade da cadeia de suprimentos nos ecossistemas.