Incidente de publicación automatizada de paquetes IndonesianFoods en el ecosistema NPM vinculado a una estafa de criptorecompensas

“Los hallazgos de Amazon son, en efecto, una continuación de la actividad del gusano IndonesianFoods que analizó nuestro equipo: un recordatorio de que la automatización al estilo de la IA facilita publicar cientos de miles de paquetes basura o riesgosos a gran escala. Los desarrolladores deberían confiar en controles automatizados para evaluar el estado de las dependencias y en análisis basados en el comportamiento, no en revisiones manuales: deben marcar los paquetes con pocas descargas, el contenido que reutiliza plantillas y los eventos de publicación masiva repentina antes de que lleguen a la compilación. Los operadores de registros también deben evolucionar: detectar de forma proactiva las cargas masivas, las plantillas que reutilizan hashes y las anomalías en el estado de los metadatos para detener estas campañas desde el origen.”

- Manoj Nair, director de Innovación, Snyk

En resumen

En noviembre de 2025, investigadores de seguridad identificaron un aumento a gran escala de publicaciones de paquetes en el registro NPM con estructuras y patrones de nombres similares. Aunque los primeros informes especularon que se trataba de un gusano, es probable que esta actividad sea el remanente de un script de automatización inactivo durante mucho tiempo y vinculado a un esquema de recompensas en criptomonedas. 

Nota: no se ha verificado ningún exploit activo en circulación y, actualmente, los paquetes afectados representan un riesgo mínimo. 

Al parecer, un desarrollador escribió un script de spam y luego lo subió como parte del spam; se trata de los remanentes de un script de publicación automatizada, originalmente vinculado a un proyecto obsoleto de recompensas en criptomonedas. Hay cinco paquetes distintos en total (copiados miles de veces con nombres ligeramente diferentes), y la única funcionalidad maliciosa consiste en publicar paquetes de forma continua. Cada paquete que contiene el script de publicación registra un promedio de apenas 18 descargas mensuales. 

Dicho esto, el evento pone de relieve la necesidad constante de mantener las dependencias en buen estado y aplicar prácticas confiables en los registros.

Componente y ecosistema involucrados

El incidente involucra un grupo de paquetes NPM publicados con varias cuentas cuyos nombres son muy parecidos, que usan plantillas de código uniformes (a menudo basadas en Next.js) y presentan pequeñas diferencias estructurales entre versiones y nombres (por ejemplo, sufijos como -wekto, -riris y -z3n). Al parecer, los paquetes se publicaron en masa a lo largo del tiempo, probablemente mediante scripts automatizados, en lugar de instalarse y explotarse en sistemas activos. Hacen referencia a una antigua campaña de recompensas en criptomonedas (tea.xyz), pero no muestran indicios confirmados de ejecución maliciosa ni de propagación autónoma una vez instalados.

Cronología del incidente

• Finales de 2023: Se publican varios paquetes base (por ejemplo, vointea y voinzaril), que inicialmente contienen código aparentemente inofensivo de aplicaciones web.

• Poco después, comienza la actividad de publicación masiva: aparecen cientos o miles de paquetes derivados que usan plantillas de código similares con sufijos renombrados.

• Una pausa de varios meses: La actividad se detiene.

• Dos meses después: Se publican en masa nuevas series (cambian los patrones de los sufijos).

• 11 de noviembre de 2025: Surgen conversaciones en la comunidad que sugieren que podría haber hasta ~44,000 paquetes involucrados (aunque la cantidad real de publicaciones masivas podría ser menor).

• 12 de noviembre de 2025: El análisis indica que los paquetes son remanentes inofensivos de una campaña antigua, no malware activo.

Paquetes NPM afectados

• Se pueden identificar alrededor de cinco paquetes “raíz” distintos (vointea, voinzaril y variantes con los sufijos wekto, riris y z3n).

• Volumen estimado de copias: probablemente miles (por ejemplo, ~4,000-5,000 paquetes), no decenas de miles; las cifras más altas incluyen versiones menores adicionales de los paquetes.

• El volumen promedio de descargas de estos paquetes es extremadamente bajo (por lo general, menos de 20 descargas al mes).

• No se ha informado de ningún compromiso confirmado de dependencias posteriores ni se ha observado ninguna cadena de explotación conocida.

• Como la ejecución del código requiere una invocación manual y no se ha identificado ninguna carga remota oculta, el riesgo para los usuarios habituales sigue siendo bajo.

Cómo ocurrió la campaña IndonesianFoods

En lugar de un gusano clásico o un evento de explotación remota, la actividad parece ser un proceso de publicación automatizada: un script que genera y publica variantes de una plantilla base de código para aplicaciones web, probablemente con fines de incentivo o experimentación (por ejemplo, en relación con una promoción de criptomonedas de “tea.xyz”).

El análisis reveló que los paquetes no contenían cargas dañinas; muchos simplemente incluían código genérico o incompleto. El proceso de publicación no tenía una condición automatizada para detenerse y parecía activarse manualmente ciertos días, en lugar de propagarse de forma autónoma a través de sistemas infectados.

Resumen de la actividad

• Uso de una o más cuentas de NPM con permisos elevados de publicación.

• Reutilización de una plantilla de código en cientos o miles de variantes.

• Paquetes con pocas descargas y uso mínimo.

• Sin cargas complejas, sigilosas o polimórficas; en cambio, hubo publicaciones masivas y evidentes.

¿Por qué no se detectó antes?

• Como los paquetes tenían pocas descargas y no producían efectos evidentes durante la ejecución, pasaron desapercibidos.

• Históricamente, las heurísticas de los registros se han centrado en los exploits o en el comportamiento malicioso posterior a la instalación, y no solo en el volumen de publicaciones.

• Al parecer, la campaña está semiabandonada; no se ha observado ninguna explotación activa.

Estrategia de detección y análisis

Qué pueden hacer los desarrolladores y las organizaciones

Los desarrolladores pueden usar herramientas como Snyk Vulnerability Database para evaluar las nuevas dependencias según su popularidad, mantenimiento, seguridad y métricas de la comunidad. 

También es importante asegurarse de que los análisis automatizados cubran tanto el estado de las dependencias como los riesgos del código con herramientas como:

• Snyk Open Source (análisis de composición de software) analiza bibliotecas de terceros para detectar vulnerabilidades conocidas y problemas de licencias. 

• Snyk Code (pruebas estáticas de seguridad de aplicaciones) analiza el código personalizado para detectar vulnerabilidades.

• Snyk Container y Snyk IaC analizan imágenes de contenedores y configuraciones de infraestructura como código, respectivamente.

En el contexto de este incidente, puedes marcar los paquetes con cantidades extremadamente bajas de descargas o contenido repetitivo en muchas versiones. También conviene monitorear las cargas a gran escala que se realizan repentinamente desde una sola cuenta y la reutilización de plantillas en distintos paquetes. Por último, aprovecha las heurísticas de metadatos, como la fecha de la última publicación, el historial de versiones, la cantidad de mantenedores y la actividad de la comunidad.

Cómo pueden mejorar el monitoreo los equipos de los registros

El monitoreo puede mejorar si se hace un seguimiento de los patrones de publicación masiva, en particular del volumen y el momento de las publicaciones por cuenta. También es importante implementar la detección de aumentos repentinos en la cantidad de publicaciones, la rotación de versiones y la reutilización de patrones de nombres. Los equipos de los registros deben incorporar verificaciones para detectar la reutilización de plantillas, lo que pueden hacer comparando los hashes de archivos de distintos paquetes. Por último, deben evaluar desde el inicio las métricas del “estado” de los metadatos, como las descargas, las estrellas del repositorio y la actividad de los mantenedores.

Mitigación y próximos pasos

Para usuarios finales y organizaciones:

1. No se requiere una mitigación inmediata si no has incluido ni instalado ninguno de los paquetes sospechosos.

2. Revisa tu grafo de dependencias para detectar paquetes sin uso o de bajo riesgo y elimina o aísla las dependencias que se usan poco.

3. Usa Snyk Advisor antes de instalar: revisa el estado del paquete y los indicadores de riesgo antes de agregar una nueva dependencia.

4. Usa npq: npq es una herramienta de código abierto que evita que se instalen este tipo de paquetes mediante heurísticas como la cantidad de descargas. 

5. Establece controles de políticas en tu CI/CD: por ejemplo, bloquea la incorporación de paquetes con una cantidad de descargas inferior a un umbral o sin commits recientes.

Palabras finales

Aunque la aparición de estas publicaciones en el registro NPM generó titulares sobre un “gusano” o un exploit de la cadena de suministro, nuestra investigación confirma que el evento no es un brote activo de malware, sino un vestigio de una automatización pasada vinculada a una campaña de criptomonedas. El riesgo inmediato para la mayoría de los usuarios es bajo. 

Sin embargo, el incidente es un recordatorio oportuno: incluso los paquetes que parecen inofensivos pueden introducir riesgos en la cadena de suministro si no se gestionan, se mantienen mal o son poco conocidos. Usar herramientas como Snyk Advisor y Snyk for JavaScript, aplicar políticas sólidas para las dependencias y mantener prácticas rigurosas de monitoreo de registros ayuda a preservar la higiene de la cadena de suministro en todos los ecosistemas.