El 30 de enero de 2026 se registró un incidente significativo en la ecosistema Open VSX: cuatro extensiones de Visual Studio Code publicadas por el desarrollador conocido como oorzc fueron actualizadas con código malicioso que incorporaba el loader de malware GlassWorm. Estas extensiones habían sido utilizadas sin problemas durante más de dos años, lo que incrementó la confianza de los usuarios y facilitó la propagación del ataque.
Incidente de GlassWorm en Open VSX: qué ocurrió y por qué importa
De acuerdo con el análisis de la empresa de seguridad Socket, los atacantes comprometieron las credenciales del autor y publicaron nuevas versiones de cuatro extensiones legítimas con funcionalidad maliciosa integrada. El equipo de seguridad de Open VSX apunta a un posible robo o filtración de tokens de acceso u otro tipo de suplantación de credenciales como vector inicial.
Las versiones comprometidas fueron retiradas rápidamente del repositorio, pero el episodio demuestra un riesgo crítico: cuando se vulnera la cuenta de un desarrollador de confianza, el ataque se propaga a través de la propia cadena de suministro de software. Las extensiones de IDE operan en un entorno altamente privilegiado, cerca del código fuente, tokens de CI/CD y secretos corporativos, lo que multiplica el impacto potencial.
Cómo funciona GlassWorm dentro de extensiones de VS Code
Loader ofuscado y descifrado en tiempo de ejecución
Las versiones maliciosas incluían un cargador (loader) GlassWorm encargado de descifrar y ejecutar el payload durante la ejecución, no de forma estática. Este enfoque dificulta el análisis tradicional, ya que la lógica maliciosa apenas es visible en el código fuente y solo se revela cuando la extensión está activa en el entorno del desarrollador.
Uso de EtherHiding para ocultar la infraestructura de mando y control
GlassWorm emplea la técnica EtherHiding, un método para encubrir la infraestructura de comando y control (C2) utilizando fuentes descentralizadas o difíciles de rastrear. De este modo, los operadores del malware pueden resolver dinámicamente nuevas direcciones de servidores C2, lo que aumenta la resiliencia de la campaña: bloquear un dominio o IP aislado no resulta suficiente para interrumpir la operación.
Robo de credenciales de desarrollo y datos de criptomonedas
Una vez activo, GlassWorm se orienta al robo de información sensible en entornos de desarrollo, con un foco particular en macOS. El payload busca específicamente:
1. Credenciales y tokens de ecosistemas de desarrollo: el malware inspecciona la configuración de npm en busca del parámetro _authToken, localiza artefactos de autenticación de GitHub y otros tokens de acceso. Con estos datos, un atacante podría acceder a repositorios privados, pipelines de CI/CD y almacenes de secretos, así como manipular procesos de build y publicación.
2. Información de criptomonedero: GlassWorm escanea el sistema en busca de archivos y artefactos asociados a criptocarteras, con el objetivo de obtener claves, frases de recuperación u otros elementos necesarios para robar fondos.
Perfilado de víctimas y cambio de táctica de los atacantes
El malware incluye mecanismos de perfilado del sistema comprometido. Antes de activar su lógica maliciosa, GlassWorm comprueba parámetros del entorno, entre ellos la configuración regional del sistema operativo. Si detecta entorno en ruso, el malware no se ejecuta. Este tipo de geoselección por idioma o región se observa con frecuencia en campañas que buscan minimizar la atención de las fuerzas de seguridad de ciertas jurisdicciones.
Otro aspecto relevante es el cambio de vector de distribución. En campañas anteriores, los operadores de GlassWorm habrían recurrido a typosquatting y brandjacking (extensiones falsas con nombres similares a plugins populares). En esta ocasión, aprovecharon un cuenta legítima con historial limpio, lo que eleva considerablemente el nivel de confianza de los usuarios y reduce la probabilidad de que se desconfíe de una actualización rutinaria.
Impacto en la cadena de suministro de software y tendencias del sector
Este incidente en Open VSX se alinea con una tendencia creciente: los ataques a la cadena de suministro de software. Informes como ENISA Threat Landscape 2023 y estudios de proveedores como Sonatype o GitHub registran un aumento sostenido de ataques contra repositorios de paquetes (npm, PyPI), marketplaces de extensiones y entornos de build. El objetivo común es situarse lo más cerca posible del código y del proceso de compilación para distribuir malware a través de canales confiables.
En este contexto, las extensiones de VS Code y Open VSX deben tratarse como componentes críticos de la cadena de suministro. Un solo plugin comprometido puede convertirse en puerta de entrada a repositorios privados, infraestructuras de automatización y activos de alto valor para la organización.
Medidas de protección para desarrolladores, equipos DevSecOps y plataformas
Para desarrolladores y mantenedores de extensiones se recomiendan acciones prioritarias como:
— habilitar autenticación multifactor (2FA) en todas las cuentas relacionadas con la publicación de paquetes;
— rotar y revocar periódicamente tokens de acceso, limitando su ámbito y vigencia según el principio de mínimo privilegio;
— almacenar secretos en gestores de secretos, evitando ficheros de configuración o variables de entorno accesibles para herramientas de terceros;
— auditar cuidadosamente cada nuevo release y sus artefactos, detectando cambios inesperados en el historial de versiones.
Para equipos de desarrollo y DevSecOps resulta clave:
— definir y mantener una lista blanca de extensiones de VS Code/Open VSX autorizadas;
— integrar el análisis de Software Bill of Materials (SBOM) y la monitorización de vulnerabilidades y compromisos de dependencias;
— desplegar soluciones EDR y herramientas de monitorización capaces de identificar comportamientos anómalos de IDEs y plugins, como conexiones de red inusuales o acceso a archivos de criptocarteras.
Por su parte, marketplaces y repositorios de extensiones deben reforzar tanto el análisis automático como la revisión manual: incorporar técnicas de análisis estático y dinámico, modelos de comportamiento para detectar actualizaciones sospechosas y mecanismos sólidos de verificación y protección de cuentas de desarrolladores, incluido 2FA obligatorio para proyectos de alto impacto.
El caso GlassWorm en Open VSX evidencia que incluso extensiones veteranas y populares pueden transformarse de un día para otro en vectores de ataque. Es recomendable revisar el inventario de plugins instalados, eliminar los que no se utilicen, actualizar desde fuentes confiables y endurecer las políticas de gestión de tokens y secretos. Tratar las extensiones y paquetes como elementos estratégicos de la cadena de suministro reducirá significativamente la probabilidad de que incidentes similares comprometan la infraestructura de desarrollo y los activos críticos de la organización.
