GlassWorm amenaza Open VSX al aprovechar dependencias de extensiones

Investigadores de seguridad han detectado una variación preocupante del operativo conocido como GlassWorm que ataca el ecosistema de extensiones para editores de código, y esta vez lo hace aprovechando una peculiaridad del registro Open VSX. En lugar de incrustar directamente un cargador malicioso en cada paquete, los atacantes están recurriendo a las relaciones entre extensiones para transformar complementos aparentemente inocuos en vectores de entrega en actualizaciones posteriores. Eso significa que una extensión que parece legítima al principio puede, con una simple actualización, comenzar a descargar código ligado a GlassWorm sin que el usuario lo espere. Puedes leer el informe técnico de la compañía que lo documentó aquí: Socket — Open VSX transitive GlassWorm campaign.

El mecanismo que explotan se basa en cómo los editores instalan extensiones indicadas en los metadatos: tanto las propiedades extensionPack como extensionDependencies en el archivo package.json provocan que el editor instale también las extensiones listadas. Esa lógica, pensada para facilitar la experiencia del desarrollador, se vuelve peligrosa cuando un actor malicioso publica primero una extensión inofensiva y más tarde la actualiza para declarar dependencias hacia paquetes comprometidos. La documentación oficial de cómo funcionan estos manifiestos ayuda a entender el detalle técnico: Documentación de manifiesto de extensiones de VS Code, y el registro donde se alojan muchas de estas extensiones es Open VSX.

Según Socket, desde finales de enero de 2026 se identificaron decenas de extensiones maliciosas en Open VSX que imitaban utilidades de uso común para desarrolladores: linters, formateadores, runners de código y complementos diseñados para asistentes de programación con IA. Las señales de abuso incluyen ofuscación más agresiva del código, rotación de direcciones de pago en la cadena de bloques Solana y el uso de esas transacciones como un “dead drop” para resolver los servidores de mando y control; técnicas que persiguen mejorar la resiliencia del ataque frente a mitigaciones tradicionales.

Paralelamente, investigadores de Aikido han documentado una táctica complementaria que se ha visto en repositorios de GitHub y paquetes npm: la inserción de caracteres Unicode invisibles en el código fuente para ocultar un cargador. Aunque esos caracteres no se aprecian al leer el archivo en un editor, la interpretación posterior permite decodificar y ejecutar un primer estadio que a su vez recupera una segunda etapa con capacidades de exfiltración de tokens, credenciales y secretos. El análisis de Aikido con ejemplos y muestras técnicas está disponible aquí: Aikido — GlassWorm returns: unicode attack, y una muestra concreta del uso de esos caracteres en un commit puede consultarse en este pull request: Commit con caracteres invisibles.

El alcance de esa infección en código abierto fue notable: Aikido estimó que más de un centenar de repositorios en GitHub fueron tocados en la primera semana de marzo de 2026, y al menos dos paquetes npm con la misma técnica fueron detectados, lo que apunta a una operación coordinada que abarca distintas plataformas de distribución de software.

Por su parte, la investigación de Endor Labs puso sobre la mesa otra variación de la amenaza en el ecosistema npm, donde se hallaron decenas de paquetes maliciosos publicados por cuentas descartables entre noviembre de 2025 y febrero de 2026. Estos paquetes usaban lo que se denomina Remote Dynamic Dependencies: dependencias cuyo origen es una URL HTTP externa en lugar del propio registro. Esa capacidad permite a los operadores cambiar el código que se entrega sin publicar una nueva versión en el registro, lo que complica la detección y el bloqueo. El informe de Endor Labs, con sus hallazgos y observaciones sobre riesgos de dependencias remotas, está aquí: Endor Labs — Return of PhantomRaven.

La autoría de esas oleadas fue objeto de debate: aunque algunos analizaron la campaña como parte del colectivo PhantomRaven, Endor Labs planteó dudas y sugerencias de que una parte del fenómeno quizá respondiera a experimentos de seguridad o investigaciones, señalando señales de alarma como la recolección masiva de datos, la rotación deliberada de cuentas y la falta de transparencia en los paquetes. Puedes consultar el contexto sobre PhantomRaven y análisis adicionales en la nota de Sonatype: Sonatype — PhantomRaven npm malware.

Más allá de la autoría, hay una lección técnica clara: cuando un paquete o extensión depende de recursos que no están versionados en el registro —ya sean paquetes remotos, direcciones en blockchain que cambian o dependencias transitorias añadidas por actualizaciones— el control del comportamiento queda en manos del publicador. Eso convierte al suministro de código abierto en una superficie de ataque dinámica donde una actualización aparentemente banal puede introducir funcionalidades con permisos amplios y consecuencias graves.

¿Qué significa esto para desarrolladores y equipos que construyen software? Primero, requiere cambiar la mentalidad respecto a la confianza implícita que se deposita en extensiones y paquetes populares: la reputación puede comprarse o recrearse y un paquete legítimo hoy puede volverse peligroso mañana. Segundo, conviene inspeccionar los manifiestos y la cadena de dependencias antes de incorporar librerías o extensiones en entornos de producción, prestando atención a entradas no estándar como dependencias apuntando a URLs externas, y a metadatos que agregan paquetes adicionales como extensionPack o extensionDependencies.

También es importante proteger credenciales y tokens con políticas de privilegios mínimos y rotación periódica, evitar almacenar secretos en variables de entorno no protegidas, usar repositorios privados o mirrors controlados cuando sea posible, y aplicar análisis automatizado de la cadena de suministro que detecte comportamientos sospechosos. Herramientas de análisis de software y escaneo de dependencias pueden ayudar a identificar paquetes que incorporan código desde fuentes fuera del registro o que realizan llamadas inusuales al entorno de ejecución.

Finalmente, la comunidad y los mantenedores de registros tienen un papel clave: revisar y endurecer los procesos de publicación, desplegar mecanismos para detectar patrones de ofuscación y dependencias dinámicas, y ofrecer señales claras al usuario sobre el origen y el alcance de lo que se instala. Open VSX y otros repositorios ya han tomado medidas para retirar extensiones maliciosas, pero la respuesta técnica y operativa debe ser continua y colaborativa entre proveedores de herramientas, equipos de seguridad y desarrolladores.

Este episodio es un recordatorio de que la comodidad de los ecosistemas modernos de desarrolladores —extensiones que se instalan automáticamente, dependencias que se resuelven con un clic— trae aparejado un coste en seguridad si no se implementan salvaguardas. La defensa contra campañas como GlassWorm exige tanto mejores prácticas individuales como mejoras sistémicas en cómo se distribuye y revisa el software libre y sus dependencias.