GlassWorm: el malware que infectó 400+ repos de Python

Actualizado el 20/03/2026: La campaña GlassWorm escaló con 72 extensiones maliciosas nuevas en Open VSX que imitan herramientas populares como ESLint, Prettier y Claude Code, usando caracteres Unicode invisibles y dependencias transitivas para inyectar payloads sin modificar la extensión original. El total de componentes comprometidos supera los 433.

La campaña GlassWorm comprometió más de 433 componentes en GitHub, npm y VS Code inyectando malware mediante tokens robados y extensiones falsas. El ataque, detectado originalmente en octubre de 2025 y resurgido con fuerza en marzo de 2026, usa técnicas que van desde force-push para reescribir el historial de Git hasta caracteres Unicode invisibles y la blockchain de Solana como canal de comando y control.

Qué es GlassWorm: el malware que se autopropaga por extensiones de VS Code

GlassWorm es el primer gusano autorréplicante diseñado específicamente para ecosistemas de extensiones de editores de código. No se trata de un paquete malicioso con nombre parecido al de una librería popular. Acá el atacante compromete repositorios legítimos, con mantenedores reales y estrellas genuinas. El código malicioso llega al mismo repo que el desarrollador ya tenía en sus dependencias.

Koi Security lo descubrió en octubre de 2025 como una extensión maliciosa aislada de VS Code. La primera versión era relativamente simple. La de marzo de 2026 es otra cosa: 433+ componentes comprometidos distribuidos en cuatro ecosistemas distintos (GitHub, npm, VS Code Marketplace y Open VSX). Y no afecta solo a VS Code. Cualquier editor basado en Open VSX, como Cursor y Windsurf, también es vulnerable a las extensiones infectadas.

Según reportes de BleepingComputer, el salto de escala entre octubre y marzo es enorme. La versión original comprometía extensiones una por una. La nueva opera como un sistema coordinado que usa las credenciales robadas de cada víctima para infectar más componentes automáticamente. Un efecto bola de nieve.

Ataque supply chain en VS Code: 72 extensiones falsas en Open VSX y 9 millones de instalaciones

La nueva oleada de GlassWorm, identificada entre enero y marzo de 2026, sumó 72 extensiones maliciosas publicadas en Open VSX, 151+ repositorios comprometidos en GitHub y múltiples paquetes npm infectados. Las cifras vienen de análisis cruzados de Aikido, Socket y Step Security, que coinciden en el total de 433 componentes comprometidos.

Lo que hace particularmente efectivo a este ataque supply chain en VS Code es la selección de extensiones a imitar. No son extensiones oscuras. Son las más populares del ecosistema: ESLint, Prettier, vscode-icons, WakaTime, Better Comments. También herramientas de IA como Claude Code y Codex. Extensiones que cualquier desarrollador instala sin pensarlo dos veces. El conteo total de instalaciones de las extensiones imitadas supera los 9 millones.

Las extensiones falsas replican la interfaz y la descripción de las originales con un nivel de detalle que dificulta distinguirlas a simple vista. Los nombres usan variaciones sutiles: un guion extra, un sufijo como “-enhanced” o “-pro”, o directamente el mismo nombre publicado por un editor distinto. En Open VSX, donde el proceso de verificación de editores es menos estricto que en el Marketplace oficial de VS Code, publicar una extensión con nombre similar es trivial.

Pero acá viene la parte más ingeniosa del vector. Las extensiones no contienen el payload malicioso directamente en su código. Usan los campos extensionPack y extensionDependencies del manifiesto para declarar dependencias hacia otras extensiones que sí llevan la carga maliciosa. Cuando instalás la extensión falsa de ESLint, automáticamente se instalan sus “dependencias” sin que veas una advertencia adicional. Y si el atacante actualiza el payload en la dependencia, tu extensión principal no muestra ninguna actualización pendiente. El código malicioso cambia sin que lo notes.

Esto representa un cambio de paradigma respecto a ataques supply chain anteriores. En incidentes como event-stream o ua-parser-js, el paquete comprometido era el mismo que el desarrollador instalaba. Acá la capa de indirección hace que la extensión visible pase cualquier auditoría manual. El problema está una capa más abajo.

Unicode invisible y blockchain: las técnicas de evasión de GlassWorm

GlassWorm usa tres técnicas de evasión que, combinadas, hacen que la detección manual sea casi imposible.

La primera es la ofuscación con caracteres Unicode del Private Use Area (rango U+FE00 a U+FE0F). Estos caracteres son invisibles en editores de código y en la interfaz web de GitHub. El código fuente parece limpio a simple vista, pero contiene bytes ocultos que un decoder interno convierte en instrucciones ejecutables y pasa a eval(). Podés mirar el archivo línea por línea y no ver nada raro. La herramienta anti-trojan-source fue diseñada específicamente para detectar este tipo de ataques Unicode en repositorios.

La segunda técnica es el abuso de dependencias transitivas que ya mencionamos. El campo extensionDependencies en el package.json de una extensión de VS Code funciona como un npm install implícito. El atacante publica una extensión limpia, la deja acumular instalaciones, y después agrega una dependencia hacia un paquete controlado. El payload llega sin que la extensión principal cambie una sola línea de código.

El tercer mecanismo es el canal de comando y control vía Solana. El malware consulta los memos de transacciones de una wallet específica cada 5 segundos. Las instrucciones vienen codificadas en base64 dentro de transacciones on-chain. No podés bloquear ese canal con un firewall convencional sin cortar el acceso a toda la blockchain de Solana. Si el canal principal falla, hay fallback por Google Calendar: el malware lee eventos de un calendario compartido para obtener la dirección del servidor C2 alternativo. Redundancia triple que complica enormemente cualquier takedown.

Cómo funciona el ataque: del token robado al código infectado

La cadena de ataque arranca con extensiones maliciosas de VS Code y Cursor. Cuando un desarrollador instala una de estas extensiones, el malware extrae tokens de autenticación de múltiples fuentes: el comando git credential fill, el almacenamiento interno de VS Code, el archivo ~/.git-credentials y la variable de entorno GITHUB_TOKEN. Con un solo token válido, el atacante tiene acceso de escritura al repositorio.

En vez de crear un pull request o un commit nuevo, el atacante hace un force-push al branch principal. Esto reescribe el historial de Git por completo. No hay PR sospechoso, no hay commit de un usuario desconocido. El código malicioso aparece como si siempre hubiera estado ahí.

La inyección se concentra en setup.py, main.py y app.py. Son archivos que se ejecutan automáticamente en distintos contextos. Un setup.py infectado corre código malicioso cada vez que alguien instala el paquete con pip install. Un main.py comprometido se ejecuta cuando el proyecto arranca.

Ejemplo concreto: un proyecto Django con 500 estrellas en GitHub. El mantenedor tiene una extensión comprometida. GlassWorm extrae su token, hace force-push al repo e inyecta código ofuscado en setup.py. Todo desarrollador que después haga pip install ejecuta el malware sin saberlo. Y el mantenedor probablemente ni se entera, porque el historial de Git no muestra nada raro.

Qué roba GlassWorm: el componente Zombi al detalle

El payload final de GlassWorm se llama internamente “Zombi” y tiene cuatro capacidades principales que van mucho más allá del robo de tokens.

Primero, el robo de credenciales. Zombi extrae tokens de NPM, GitHub, Git, OpenVSX y cualquier credencial almacenada en el sistema de credenciales del editor. Estos tokens alimentan directamente el ciclo de autopropagación: cada nueva víctima aporta accesos que el gusano usa para comprometer más repositorios.

Segundo, el targeting de wallets cripto. Zombi apunta a 49+ extensiones de navegador relacionadas con criptomonedas. MetaMask, Phantom, Coinbase Wallet y Exodus están en la lista, junto con decenas de wallets menos conocidas. El malware descarga Node.js en la máquina infectada y ejecuta un stealer en JavaScript específico para cada wallet. No es un ataque genérico: tiene código dedicado para cada extensión de wallet, lo que sugiere un esfuerzo de desarrollo considerable detrás.

Tercero, acceso remoto. Zombi instala un servidor VNC oculto en la máquina comprometida. Esto le da al atacante control visual completo del escritorio de la víctima, sin que aparezca ninguna ventana o indicador visible. Pueden operar la máquina como si estuvieran sentados frente a ella.

El cuarto componente es un proxy SOCKS5 que convierte la máquina infectada en un nodo de tránsito. El tráfico de otros atacantes pasa a través de tu conexión, haciendo que las actividades maliciosas parezcan originarse desde tu IP. Tu máquina pasa a formar parte de una botnet sin que lo sepas.

Alcance del daño: comparación entre oleadas y ecosistemas afectados

Oleada original vs. oleada de marzo 2026

La campaña que StepSecurity bautizó como ForceMemo es particularmente preocupante. Los proyectos Python afectados incluyen aplicaciones Django, proyectos de investigación en machine learning, dashboards de Streamlit y paquetes publicados en PyPI. Son proyectos reales, con usuarios reales, que de un día para otro empezaron a distribuir malware sin que nadie lo notara.

Un detalle que se repite en este tipo de campañas: el malware incluye un check de idioma del sistema operativo y no se ejecuta en máquinas configuradas en ruso. Es un patrón clásico de malware originado en países de la ex Unión Soviética, donde los atacantes evitan comprometer sistemas locales para reducir la probabilidad de investigación por parte de autoridades nacionales.

Por qué los desarrolladores son el blanco perfecto para un ataque supply chain

Un desarrollador comprometido no es una víctima más. Es una puerta de entrada a toda la cadena de suministro de software de una organización. Un solo dev con acceso de escritura a un repositorio interno puede, sin saberlo, propagar malware a producción a través del pipeline de CI/CD. Las credenciales de un mantenedor de un paquete npm popular comprometen a todos los que dependen de ese paquete. Si te interesa, podés leer más sobre integrar APIs de terceros en tus proyectos.

El problema de fondo es la confianza implícita. Los marketplaces de extensiones funcionan sobre la premisa de que lo que se publica ahí fue revisado y es seguro. Pero la realidad es que ni el Marketplace de VS Code ni Open VSX tienen procesos de revisión comparables a lo que hace, por ejemplo, Apple con su App Store. La barrera de entrada para publicar una extensión es baja, y la verificación de editores es superficial.

Los AI coding assistants amplían la superficie de ataque de una forma que no se discute lo suficiente. Herramientas como Cursor, Windsurf y extensiones de IA para VS Code procesan código de manera automática, ejecutan snippets y acceden a archivos del proyecto. Si la extensión de IA está comprometida, el atacante tiene acceso al contexto completo del proyecto en el que estás trabajando. Código fuente, variables de entorno, archivos de configuración con secretos. Todo.

Cómo detectar si estás infectado por GlassWorm

Hay indicadores concretos que podés verificar ahora mismo en tu máquina.

El más directo: buscá la variable lzcdrtfxyqiplpd en el código de tus extensiones instaladas. Es un identificador interno de GlassWorm que aparece en todas las variantes conocidas. Si la encontrás, esa extensión está comprometida.

Verificá si existe el archivo ~/init.json en tu directorio home. GlassWorm lo usa como archivo de configuración. También buscá instalaciones inesperadas de Node.js fuera de las rutas habituales, particularmente en tu carpeta home. El malware descarga su propio runtime de Node para ejecutar el stealer de wallets independientemente de si tenés Node instalado o no.

En repositorios clonados, revisá si hay archivos i.js que no deberían estar ahí. GlassWorm inyecta este archivo en repos comprometidos como parte de su payload. También auditá el historial de commits de Git buscando force-pushes sospechosos, especialmente en branches principales. Un git reflog puede mostrar reescrituras de historial que no son visibles en git log.

Para detectar la ofuscación Unicode, la herramienta anti-trojan-source escanea archivos buscando caracteres del Private Use Area que son invisibles en editores convencionales. Corré esta herramienta contra tu directorio de extensiones y contra cualquier repositorio que hayas clonado recientemente. También es buena idea monitorear conexiones de red salientes: el malware consulta la blockchain de Solana cada 5 segundos, lo que genera un patrón de tráfico detectable.

Cómo proteger tu entorno de desarrollo

Las medidas más urgentes son las más simples. Auditá tu lista de extensiones instaladas y eliminá todo lo que no uses activamente. Cada extensión es una superficie de ataque potencial. Desactivá las actualizaciones automáticas de extensiones: mejor revisar manualmente qué se actualiza y por qué antes de aceptar cambios.

Instalá extensiones exclusivamente desde editores verificados en el Marketplace oficial de VS Code. Si usás un editor basado en Open VSX (Cursor, Windsurf), sé especialmente cuidadoso con las extensiones que instalás. Verificá el nombre del editor, la cantidad de instalaciones y la fecha de publicación. Una extensión popular publicada hace dos semanas por un editor sin otros paquetes es una señal de alerta. También te puede interesar este análisis en nuestro blog de IA: alertas recientes de CISA sobre brechas de seguridad.

Si creés que hubo exposición, rotá inmediatamente todos tus tokens: GitHub, NPM, Git y cualquier otro servicio al que accedas desde tu editor. Revisá los permisos de tus tokens y limitá los scopes al mínimo necesario. Un token de GitHub con permisos de escritura a todos tus repos es una invitación abierta para GlassWorm. También te puede interesar este análisis en nuestro blog de IA: los crecientes riesgos de seguridad en la industria tech.

Para proyectos npm, Aikido Safe Chain es una herramienta open source que monitorea dependencias transitivas en npm, yarn y pnpm. Escanea el árbol de dependencias completo y alerta sobre paquetes sospechosos. Implementar YARA rules para detección automatizada también ayuda, sobre todo en entornos CI/CD donde podés agregar un paso de escaneo antes de cada build. Si tu equipo administra infraestructura con Donweb u otro proveedor de hosting, asegurate de que los tokens de deploy estén aislados y no se expongan en el entorno de desarrollo local.

Respuesta de la industria y lecciones para el ecosistema open source

Microsoft removió las extensiones reportadas del VS Code Marketplace, pero la respuesta tardó más de lo aceptable según varios investigadores. Open VSX actuó más rápido en las últimas semanas, aunque el daño ya estaba hecho con 72 extensiones activas durante semanas. GitHub implementó alertas para force-pushes sospechosos en repositorios populares, pero solo para repos con más de cierta cantidad de estrellas.

El debate de fondo es si los marketplaces de extensiones necesitan un modelo de seguridad completamente distinto. Hoy cualquiera puede publicar una extensión con nombre similar a una herramienta popular. No hay firma de código obligatoria, no hay sandbox real para extensiones, y el proceso de revisión es mayormente automatizado. GlassWorm expuso esas debilidades de una forma que ataques anteriores como event-stream (2018), ua-parser-js (2021) o colors.js (2022) no habían logrado.

Eso sí, habría que ver si la respuesta de la industria va más allá de parches reactivos. Se habla de verificación más estricta de editores, de sandboxing real para extensiones y de auditorías obligatorias para paquetes con más de cierto número de dependientes. Suena bien en teoría, pero implementarlo sin romper la experiencia de los desarrolladores es un desafío enorme. El ecosistema open source funciona justamente porque la barrera de entrada es baja.

Qué está confirmado y qué todavía no

Confirmado

• 72 extensiones maliciosas publicadas en Open VSX entre enero y marzo de 2026, ya removidas.
• 151+ repositorios de GitHub comprometidos mediante force-push con tokens robados.
• 433+ componentes totales identificados por Aikido, Socket y Step Security.
• Canal C2 vía blockchain de Solana con fallback por Google Calendar.
• El componente Zombi roba tokens, apunta a 49+ wallets cripto e instala VNC oculto.
• Las extensiones falsas imitan ESLint, Prettier, vscode-icons, WakaTime, Better Comments, Claude Code y Codex.
• Editores basados en Open VSX (Cursor, Windsurf) también son vulnerables.
• Caracteres Unicode del rango U+FE00–U+FE0F usados para ofuscar código malicioso.

Pendiente de confirmación

• El número exacto de paquetes npm comprometidos. Las cifras varían según la fuente.
• Si hay extensiones maliciosas todavía activas en alguno de los marketplaces que no fueron detectadas.
• El monto total de criptomonedas robadas a través de las wallets comprometidas.
• La atribución del ataque. El check de locale ruso sugiere un origen geográfico, pero no hay confirmación oficial de ningún grupo específico.
• Si el canal de Google Calendar fue efectivamente usado o es solo un mecanismo de fallback latente.

Qué significa para equipos de desarrollo en Latinoamérica

Los equipos de desarrollo en la región tienden a usar extensiones de VS Code sin políticas formales de seguridad sobre qué se puede instalar y qué no. En empresas grandes quizás hay controles, pero en startups, agencias y equipos freelance, cada dev instala lo que necesita sin pasar por ningún filtro. GlassWorm explota exactamente esa dinámica.

Otro factor: muchos equipos latinoamericanos mantienen paquetes npm y proyectos open source que, si bien no tienen millones de descargas, sí forman parte de cadenas de dependencias de productos en producción. Un proyecto de un dev argentino con 200 estrellas puede ser dependencia de un sistema que usa una empresa en México. La cadena de suministro no respeta fronteras.

La recomendación práctica para equipos en la región es establecer una lista blanca de extensiones permitidas, auditar las que ya están instaladas y rotar tokens como parte de una rutina periódica, no solo como respuesta a incidentes. Son medidas que no cuestan nada y reducen significativamente la superficie de ataque.

Este caso se suma a una tendencia preocupante en la cadena de suministro de software, como analizamos en GlassWorm: ataque supply-chain infecta 72 extensiones de VS .

Esto se relaciona con lo que analizamos en GlassWorm inyecta malware en 400+ repos de Python en GitHub, donde el vector de ataque también apunta a la cadena de suministro.

Este tipo de amenazas se viene multiplicando, como analizamos en GlassWorm: ataque supply-chain infecta 72 extensiones de VS , donde el vector de entrada fue similar.

En ese mismo contexto de seguridad, cubrimos en profundidad GlassWorm inyecta malware en 400+ repos de Python en GitHub.

Esto se conecta con GlassWorm inyecta malware en 400+ repos de Python en GitHub, donde cubrimos el impacto completo de estos ataques.

Esto se parece a lo que pasó con GlassWorm: ataque supply-chain infecta 72 extensiones de VS , donde los usuarios no vieron venir nada.

Profundizamos en esto con GlassWorm: ataque supply-chain infecta 72 extensiones de VS Code, que ejemplifica cómo operan estos ataques modernos.

Acá documentamos un caso similar: GlassWorm: ataque supply-chain infecta 72 extensiones de VS.

Preguntas frecuentes

¿Qué es GlassWorm y qué extensiones de VS Code infectó?

GlassWorm es un gusano autopropagante que infectó 72 extensiones en Open VSX y comprometió más de 433 componentes en total entre GitHub, npm y marketplaces de extensiones. Las extensiones maliciosas imitan herramientas populares como ESLint, Prettier, vscode-icons, WakaTime, Better Comments y herramientas de IA como Claude Code y Codex. Los editores basados en Open VSX como Cursor y Windsurf también están afectados.

¿Cómo saber si mis extensiones de VS Code tienen malware?

Buscá la variable lzcdrtfxyqiplpd en el código de tus extensiones, revisá si existe el archivo ~/init.json y verificá si hay instalaciones inesperadas de Node.js en tu directorio home. Usá la herramienta anti-trojan-source para detectar caracteres Unicode ocultos. Si encontrás cualquiera de estos indicadores, desinstalá la extensión sospechosa y rotá todos tus tokens inmediatamente.

¿Cómo protegerse del ataque supply chain en npm y VS Code?

Auditá y reducí tus extensiones instaladas al mínimo necesario, desactivá las actualizaciones automáticas y verificá el editor antes de instalar. Para npm, usá Aikido Safe Chain para monitorear dependencias transitivas. Rotá periódicamente tus tokens de GitHub, NPM y Git, y limitá sus permisos al mínimo scope necesario. En entornos de equipo, establecé una lista blanca de extensiones aprobadas.

¿Qué datos roba GlassWorm y qué wallets están en riesgo?

El componente Zombi de GlassWorm roba tokens de NPM, GitHub, Git y OpenVSX, y apunta específicamente a 49+ extensiones de wallets cripto incluyendo MetaMask, Phantom, Coinbase Wallet y Exodus. Además instala un servidor VNC oculto para acceso remoto completo y un proxy SOCKS5 que convierte la máquina en nodo de tránsito para tráfico malicioso.

Conclusión

GlassWorm pasó de ser una extensión maliciosa aislada en octubre de 2025 a una operación de 433+ componentes comprometidos en marzo de 2026. La nueva oleada de 72 extensiones en Open VSX, con técnicas de evasión como Unicode invisible y dependencias transitivas, demostró que los marketplaces de extensiones no están preparados para ataques de esta sofisticación.

Lo que cambió con esta nueva oleada es el nivel de indirección. Ya no alcanza con revisar el código de la extensión que instalás. Tenés que auditar sus dependencias, verificar al editor y monitorear cambios en paquetes transitivos. Eso es un problema real para desarrolladores individuales y equipos chicos que no tienen infraestructura de seguridad dedicada.

De acá en adelante, conviene hacer tres cosas: auditar las extensiones instaladas contra la lista de IoCs conocidos, rotar tokens de acceso como medida preventiva y establecer algún proceso mínimo de validación antes de instalar extensiones nuevas. GlassWorm fue detectado y contenido, pero el modelo de ataque que inauguró, extensiones falsas con payloads en dependencias transitivas, es replicable. Es cuestión de tiempo hasta que aparezca una campaña similar.

Fuentes

• Aikido — GlassWorm Returns: Unicode Attack on GitHub, npm and VS Code
• The Hacker News — GlassWorm Supply Chain Attack Abuses 72 Extensions
• BleepingComputer — GlassWorm Malware Hits 400+ Code Repos
• CyberInsider — New GlassWorm Supply Chain Wave Hits Open VSX
• Snyk — Defending Against GlassWorm