La comunidad de JavaScript enfrenta una campaña de publicación masiva en npm atribuida al gusano IndonesianFoods, capaz de crear nuevos paquetes cada 7–10 segundos. Según Sonatype, ya se han emitido más de 100.000 publicaciones con nombres pseudoaleatorios —a menudo alusivos a platos indonesios—. Aunque no se han detectado cargas maliciosas activas dentro de los paquetes, el alto grado de automatización y el volumen elevan el riesgo para la cadena de suministro de software.
Escala y automatización del ataque en npm
El investigador Paul McCarthy fue de los primeros en rastrear la campaña, publicando un contador en tiempo real de cuentas relacionadas y paquetes. Sonatype detalla que los intentos se remontan al 10 de septiembre de 2025 (paquete fajar-donat9-breki), aunque entonces la autorreplicación no tuvo impacto significativo. La oleada actual es inédita por su ritmo y alcance: Amazon Inspector, al etiquetar estos paquetes mediante OSV advisory, dispara notificaciones en masa, y la telemetría de Sonatype registró 72.000 nuevos avisos en un solo día, un volumen que tensiona los sistemas de defensa y genera fatiga de alertas.
Cómo opera IndonesianFoods: autorreplicación sin hooks de instalación
El gusano reside en un único fichero JavaScript por paquete (auto.js o publishScript.js). No se activa de forma automática ni abusa de postinstall; requiere ejecución manual (por ejemplo, node auto.js). Una vez iniciado, el script entra en bucle: elimina el atributo «private»: true del package.json, genera un nuevo nombre y versión para evadir duplicados y publica con npm publish. El resultado es una contaminación acelerada del registro, mayor carga sobre la infraestructura y ruido en las búsquedas, con el consiguiente riesgo de instalación accidental y compromiso de la cadena de suministro.
Motivación económica: abuso del TEA Protocol
Endor Labs halló en varios paquetes archivos tea.yaml con credenciales y monederos, lo que apunta a un intento de explotar TEA Protocol, una plataforma blockchain que recompensa con tokens el “impacto” en proyectos de código abierto. La hipótesis operativa es clara: cuantas más publicaciones y mayor impact score, más recompensas potenciales. El patrón sugiere una evolución por fases: ≈43.000 paquetes en 2023, monetización vía TEA desde 2024 y, en 2025, la autorreplicación que convierte IndonesianFoods en un gusano de spam a escala industrial.
Impacto en la cadena de suministro: ruido como vector de oportunidad
Aunque no se han confirmado robos de datos ni puertas traseras en esta campaña, persiste el riesgo de una “sustitución en caliente” de payloads: una actualización menor o una dependencia satélite podría introducir código malicioso cuando las defensas estén saturadas por el ruido. Esta táctica encaja con incidentes recientes como GlassWorm (OpenVSX y Visual Studio Code Marketplace) y Shai-Hulud (cientos de paquetes en npm), donde campañas de fácil despliegue sirven de cortina para intrusiones más sofisticadas en ecosistemas open source.
Recomendaciones prácticas para mitigar el riesgo
Para equipos de desarrollo
– Fije versiones y use lockfiles; limite actualizaciones mediante allowlist.
– Implemente un proxy/registro privado (p. ej., Verdaccio, Artifactory) con cuarentena para paquetes nuevos o no verificados.
– Active 2FA en npm y adopte provenance/attestations cuando estén disponibles.
– Ejecute CI con –ignore-scripts por defecto y bloquee lifecycle hooks arbitrarios.
– Aplique SCA (Sonatype, Endor Labs, osv-scanner) y monitorice anomalías de publicación y dependencia.
– Evite búsquedas indiscriminadas en el registro y controle rangos flexibles (caret/tilde).
Para registradores y ecosistemas
– Aplique rate limiting de publicaciones, analítica de comportamiento y cuarentena automática de series sospechosas.
– Refuerce la verificación de mantenedores y dedup de código plantilla.
– Coordine avisos entre OSV y escáneres para reducir la fatiga de alertas sin perder visibilidad.
IndonesianFoods evidencia cómo campañas “ruidosas” pueden erosionar la confianza en npm y abrir la puerta a ataques de mayor calado. Es recomendable revisar la política de dependencia, endurecer los flujos de publicación y priorizar la detección de anomalías. Adoptar estas medidas de forma proactiva reduce la probabilidad de que la próxima oleada de paquetes de spam sea el preámbulo de un incidente real en su cadena de suministro.
