GlassWorm regresa: la campaña de la cadena de suministro que oculta malware con Unicode invisible en repos, paquetes y extensiones

La campaña de comprometimiento de la cadena de suministro conocida como GlassWorm ha reaparecido con una oleada coordinada mucho más amplia que la observada inicialmente. Investigadores de varias comunidades y empresas de seguridad —entre ellos Aikido, Socket, Step Security y la comunidad de OpenSourceMalware— han identificado cientos de paquetes, repositorios y extensiones afectados en plataformas como GitHub, npm y los marketplaces de extensiones para editores.

En esta nueva fase el alcance es notable: se han documentado centenas de repositorios Python y JavaScript en GitHub, decenas de extensiones en VSCode/OpenVSX y varios paquetes publicados en npm que contienen código troceado u ofuscado mediante caracteres Unicode “invisibles”. La técnica de insertar caracteres no imprimibles facilita que el código malicioso pase desapercibido para revisiones superficiales y filtros automáticos, porque el archivo puede verse aparentemente legítimo para ojos humanos y scanners que no normalicen el texto.

La investigación conjunta apunta a un mismo operador detrás de las distintas oleadas: los reportes remarcan el uso reiterado de una dirección en la blockchain de Solana como canal de comando y control, la reutilización de infraestructuras y payloads con funcionalidad equivalente, y patrones de ofuscación y persistencia comparables entre proyectos afectados. Estos detalles son los que permiten a los analistas correlacionar incidentes y sugerir que no se trata de ataques aislados, sino de una campaña centralizada.

Técnicamente, la infección suele empezar con la toma de control de cuentas en GitHub y la introducción de commits maliciosos mediante force-push. A partir de ahí los atacantes publican paquetes o extensiones a registries como npm o OpenVSX. El malware incluye una rutina que consulta la blockchain de Solana cada pocos segundos en busca de instrucciones codificadas en transacciones —los investigadores de Step Security documentaron cerca de 50 transacciones relevantes entre finales de noviembre de 2025 y mediados de marzo de 2026— y esas instrucciones dirigen la descarga y ejecución de un runtime de Node.js que despliega un ladrón de información escrito en JavaScript.

Los objetivos del software espía son claros: extracción de datos de monederos de criptomonedas, credenciales, tokens de acceso, claves SSH y artefactos del entorno de desarrollo que permiten pivotar y robar repositorios o credenciales adicionales. En algunas campañas previas también se han observado binarios macOS trojanizados —por ejemplo clientes falsificados de monederos hardware— y extensiones comprometidas que llegaban a IDEs no soportados a través de OpenVSX, como describió un investigador en análisis sobre OpenVSX.

Los análisis del código apuntan a autores que comentan en ruso y a una lógica que evita ejecutarse en sistemas configurados en esa lengua; sin embargo, ese dato por sí solo no basta para atribuir con certeza la responsabilidad a una nación o un grupo específico. La atribución requiere más evidencia operativa y corroboración por múltiples fuentes.

Si trabajas con dependencias instaladas directamente desde repositorios o sueles clonar proyectos para ejecutarlos, conviene revisar indicadores técnicos que los analistas han compartido. Uno de ellos es la presencia de una variable marcador identificada como “lzcdrtfxyqiplpd”, que ha servido como signo revelador en varios repositorios comprometidos. También se ha detectado persistencia mediante un fichero de configuración local (~/init.json) y la instalación silenciosa de versiones de Node.js en directorios de usuario (como ~/node-v22*), además de archivos sospechosos con nombres como i.js en proyectos recién clonados y commits cuyos metadatos muestran diferencias extrañas entre la fecha del autor y la del committer.

Ante este escenario, las medidas de contención y mitigación pasan por rotar claves y tokens que hayan podido estar expuestos, auditar el historial de commits y los paquetes publicados por cuentas propias, y buscar artefactos mencionados en sistemas de desarrollo. También es recomendable habilitar controles adicionales en las cuentas de repositorios: activar la autenticación de dos factores, revisar sesiones activas y claves SSH autorizadas, y limitar tokens con permisos mínimos. GitHub y otros proveedores publican guías para asegurar cuentas y repositorios; por ejemplo, la documentación sobre 2FA de GitHub es un buen punto de partida: https://docs.github.com/…/two-factor-authentication-2fa.

Para equipos de desarrollo y administradores de plataformas, es crítico tratar las dependencias como código potencialmente no confiable: validar firmas cuando existan, fijar versiones en los archivos de lock, revisar cambios en paquetes transitorios y aprovechar herramientas de análisis de la cadena de suministro que escanean repositorios y registros de paquetes. Los mantenedores de registries y marketplaces también deben mejorar la detección de patrones de ofuscación Unicode y reforzar los procesos de verificación de cuentas y publicaciones.

En cuanto a la respuesta ante incidentes, conviene conservar evidencia (logs, builds, copias de archivos comprometidos), desconectar máquinas infectadas de redes de desarrollo y realizar un inventario de secretos que podrían haber sido exfiltrados. Las organizaciones que dependen de código abierto en producción deberían considerar controles de prevención adicionales, como entornos de build aislados, firmas reproducibles y pipelines que no ejecuten código de terceros sin revisión previa.

GlassWorm nos recuerda que la seguridad del software moderno no se limita al código que escribimos, sino que se extiende a la enorme superficie que forman repositorios, paquetes y extensiones de terceros. La cadena de suministro del software es tan fuerte o tan débil como el eslabón menos protegido, y esta campaña demuestra cómo actores con práctica y recursos pueden moverse lateralmente a través de herramientas y servicios legítimos para alcanzar objetivos valiosos.

Si quieres profundizar en los informes técnicos y revisar los indicadores publicados por los equipos que han analizado esta amenaza, puedes consultar los artículos de Aikido sobre el regreso de GlassWorm (aquí), el análisis de OpenVSX por Socket (aquí), y el desglose de Step Security sobre la campaña y las señales de compromiso (aquí). Para entender cómo las transacciones de Solana pueden llevar memos con instrucciones, la documentación oficial de Solana sobre el programa Memo es una referencia útil: https://docs.solana.com/…/programs#memo-program.

La comunidad de seguridad y los desarrolladores deben mantenerse alerta y compartir indicadores y mitigaciones para frenar esta y otras campañas similares. La colaboración entre responsables de infraestructuras, mantenedores de proyectos de código abierto y proveedores de registries es imprescindible para reducir la ventana de exposición y elevar la barra de protección para todos.