La campaña oculta malware en npm y Go dentro de VS Code que se activa al abrir tu proyecto

Investigadores en ciberseguridad han desentrañado una campaña reciente que aprovechó paquetes maliciosos tanto en npm como en el ecosistema Go para introducir un robador de información basado en Python en máquinas Windows, Linux y macOS. Lo relevante no es sólo el malware en sí, sino la táctica: los atacantes escondieron la ejecución dentro de una tarea automática de Visual Studio Code y disfrazaron código JavaScript como un archivo de fuente, con lo que convierten un flujo de trabajo cotidiano del desarrollador en vector de infección.

Los paquetes npm identificados —entre ellos html-to-gutenberg y fetch-page-assets, que incluían dependencias comprometidas— fueron subidos a finales de mayo de 2026 y ya no están disponibles en el registro. En paralelo, análisis de la comunidad señalaron al menos 16 repositorios Go que habían publicado versiones con la misma carga maliciosa. La ejecución inicial se activa cuando el directorio del paquete se abre como espacio de trabajo en VS Code y la tarea maliciosa marcada con runOn: 'folderOpen' se ejecuta automáticamente; esa opción está documentada en la propia guía de tareas de VS Code y es precisamente el mecanismo que abusaron los atacantes https://code.visualstudio.com/docs/editor/tasks#_runon.

La cadena de ataque es sofisticada y escalonada: el supuesto archivo de fuente contiene JavaScript que recupera un siguiente estadio cifrado desde transacciones en blockchains (usando servicios como TronGrid y Aptos) —una técnica de “dead drop” que dificulta la toma abajo del contenido—, configura una conexión a infraestructura controlada por el atacante, activa un backdoor sobre Socket.io y finalmente descarga e instala un infostealer en Python. El componente final recoge credenciales de navegadores, gestores, wallets, almacenes de credenciales del sistema operativo y artefactos de desarrollo (como credenciales de Git y datos de VS Code), empaqueta la información y la exfiltra, incluso a través de un bot de Telegram si el atacante proporcionó un token.

Además del impacto directo en la confidencialidad de credenciales y fondos de criptomonedas, este incidente subraya dos tendencias preocupantes: primero, los atacantes orientan sus campañas al perfil “desarrollador” y usan herramientas legítimas (IDEs, paquetes populares) para camuflar su actividad; segundo, la reutilización de infraestructuras resilientes (blockchain como almacén de etapas) aumenta la persistencia y la dificultad de mitigación.

Para equipos y desarrolladores la recomendación inmediata es contundente: elimine cualquier dependencia sospechosa o versiones publicadas en las fechas señaladas y busque pistas de ejecución automática en las máquinas de desarrollo. En particular, inspeccione carpetas .vscode en proyectos locales y cuentas de desarrollador en repositorios públicos; verifique si existen tasks.json con opciones que permitan ejecutar comandos al abrir la carpeta y revise archivos binarios o “fuentes” que contengan código JavaScript en lugar de datos de fuente legítimos. Si detecta compromiso activo —conexiones salientes inusuales, procesos desconocidos o archivos comprimidos con datos sensibles— contemple el aislamiento y la reinstalación de sistemas afectados y coordine una respuesta forense para determinar el alcance.

Desde el punto de vista de la gestión de riesgo, es imprescindible rotar credenciales tras una posible exposición: cambie contraseñas y API keys, reemplace tokens y claves de servicio en la nube, invalide sesiones y clientes OAuth, y asegure el acceso a monederos cripto (migración de fondos a wallets nuevas con claves privadas seguras si hay sospecha de robo). Active autenticación multifactor y prefiera gestores de contraseñas dedicados frente al almacenamiento en navegadores. Para cuentas de registro (npm, GitHub, etc.) habilite 2FA y políticas de verificación de paquetes.

En el plano organizativo, adopte controles de higiene en la cadena de suministro de software: implemente bloqueo de versiones y firmas de paquetes cuando sea posible, utilice herramientas de Software Composition Analysis (SCA) y políticas de aprobación para dependencias nuevas, y ejecute builds y análisis en entornos CI/CD controlados que no dependan del workspace del desarrollador. GitHub ofrece guías y funcionalidades orientadas a la seguridad de la cadena de suministro que pueden ayudar a establecer estas prácticas https://docs.github.com/en/code-security/supply-chain-security. Igualmente, configure políticas de “workspace trust” y evite permitir la ejecución automática de tareas desde directorios no verificados.

Los incidentes como este también requieren un enfoque proactivo: monitorización de red para detectar comunicaciones hacia dominios o patrones inusuales (incluido tráfico hacia APIs de blockchain y proxies), auditoría continua de dependencias y la producción de SBOMs (Software Bill of Materials) para poder identificar rápidamente qué software podría haber estado en riesgo. Si maneja activos con fondos en cripto, automatice alertas sobre movimientos de fondos y establezca procedimientos de emergencia para su traslado seguro.

Finalmente, la comunidad debe tomar nota de que las defensas tradicionales de registro de paquetes y controles en ejecución no bastan si la cadena de entrega puede activar funcionalidades del IDE o apoyarse en infraestructura descentralizada para alojar etapas. Este caso es un recordatorio de que la seguridad del desarrollo no es sólo responsabilidad de operaciones o de un solo equipo: requiere coordinación entre desarrolladores, responsables de seguridad, administradores de repositorios y proveedores de herramientas.