Detectan 14 paquetes maliciosos en npm; Microsoft pide a desarrolladores reemplazar urgentemente las claves de AWS y los secretos de GitHub Actions.

En los ataques contra desarrolladores cada vez basta menos con la intrusión de una gran plataforma y más con un solo paquete bien disfrazado. Un caso reciente con npm muestra cuán rápido el código malicioso puede llegar a entornos de trabajo donde se almacenan claves de nubes, repositorios y sistemas de compilación.

Microsoft informó que un usuario de npm publicó en cuatro horas 14 paquetes maliciosos, similares a bibliotecas populares para OpenSearch, Elasticsearch, tareas de DevOps y configuración de entornos. Para las publicaciones se usó una nueva cuenta de mantenedor con el alias vpmdhaj y la dirección a39155771@gmail[.]com.

Según Microsoft, el autor del ataque claramente apuntó a desarrolladores que pueden tener credenciales de AWS, Elastic Cloud y otros servicios en sus entornos. Los paquetes falsos imitaban bibliotecas legítimas de los ecosistemas @opensearch y @elastic, y también se dirigían a Amazon Web Services, HashiCorp Vault, GitHub Actions y al propio registro npm.

Los 14 paquetes ya fueron eliminados. Microsoft publicó la lista completa de nombres y recomendó verificar los sistemas donde las versiones afectadas pudieron instalarse o incorporarse a compilaciones desde el 28 de mayo de 2026. Es preferible reemplazar las credenciales potencialmente comprometidas de AWS IAM/STS, HashiCorp Vault, las publicaciones en npm y GitHub Actions.

Para engañar se usaron dos técnicas. Algunos paquetes recibieron nombres con errores tipográficos, similares a bibliotecas reales. Otros parecían herramientas auxiliares para OpenSearch y Elasticsearch, por ejemplo opensearch-setup-tool, opensearch-config-utility y elastic-opensearch-helper.

Además, el autor falsificó metadatos, indicando en package.json enlaces al proyecto real opensearch-js en GitHub, y aumentó inmediatamente los números de versión a valores como 1.0.7265 o 2.1.9201 para dar la apariencia de un proyecto maduro.

Tras la instalación, el código malicioso se ejecutaba automáticamente mediante ganchos preinstall. La primera versión del cargador recopilaba datos del sistema, incluyendo el nombre del host, la plataforma, la arquitectura, la versión de Node.js, el nombre de usuario, el directorio de trabajo y la información sobre el paquete, y luego enviaba la información a un servidor de control. Como respuesta se descargaba la segunda etapa, que se guardaba como payload.bin.

Microsoft señala que index.js volvía a ejecutar payload.bin en cada carga posterior del módulo, por lo que el malware podía sobrevivir a varias etapas de compilación y ejecuciones repetidas en el entorno del desarrollador.

Una versión posterior del cargador actuaba de forma más sigilosa: comprobaba la presencia de Bun en el host, y si era necesario descargaba el entorno legítimo Bun v1.3.13 y ejecutaba la carga útil para robar secretos de AWS, HashiCorp Vault, npm, GitHub Actions y otros entornos CI/CD.