.png)
Dieciocho Minutos, 2,2 Millones de Objetivos
Ha sido una semana difícil para GitHub. Ayer, GitHub confirmó haber sido comprometido. Según se informa, los atacantes extrajeron datos de aproximadamente 3.700 repositorios internos, y el punto de entrada fue una extensión de VS Code maliciosa ejecutándose en la máquina de un empleado de GitHub.
El día anterior, Nx Console (una popular extensión de VS Code para el sistema de compilación monorepo Nx) mostró el mecanismo que hizo posible la vulneración. En cuanto a seguridad, las extensiones de VS Code son el Salvaje Oeste.
¿Qué pasó con Nx Console?
El 18 de mayo, la versión 18.95.0 de la extensión Nx Console (2,2 millones de instalaciones, insignia de editor verificado) fue subida al Visual Studio Marketplace a las 12:30 UTC. Microsoft no marcó la subida. El mantenedor de Nx no recibió el correo electrónico de notificación de subida del marketplace hasta las 12:36 UTC, seis minutos después. La compilación comprometida fue retirada a las 12:47 UTC y Microsoft registró completamente la eliminación a las 12:48 UTC. Exposición total en el Visual Studio Marketplace: aproximadamente dieciocho minutos.
La misma compilación también se publicó en OpenVSX. Informes anteriores indicaban que OpenVSX no se había visto afectado, pero el aviso actualizado de los mantenedores lo sitúa en línea desde las 12:33 UTC hasta las 13:09 UTC. Eso es aproximadamente treinta y seis minutos, el doble de la ventana del Visual Studio Marketplace.
Según el aviso, cualquiera que tuviera Nx Console instalado con la actualización automática habilitada durante esos periodos debería asumir que fue comprometido, y cualquier cosa en disco (tokens, secretos, claves SSH, cualquier elemento adyacente a credenciales) necesitaba ser rotado.
La causa raíz fue un token de GitHub de un colaborador que había sido extraído en un ataque anterior a la cadena de suministro y luego utilizado para publicar la versión maliciosa. El pipeline de publicación aceptó el token robado sin verificarlo, que era todo lo que los atacantes necesitaban.
La actualización automática es el problema real
Cada marketplace de extensiones popular se distribuye con la actualización automática activada por defecto. VS Code, Cursor, toda la gama. El razonamiento tiene sentido de forma aislada, porque la mayoría de los desarrolladores nunca actualizan nada manualmente, por lo que desactivarlo significa una larga cola de editores ejecutando código obsoleto y vulnerable.
La compensación deja de tener sentido una vez que se tienen en cuenta los editores hostiles/comprometidos. La actualización automática proporciona a un atacante que controla una versión un canal de envío directo a cada máquina que ejecuta esa extensión. Los marketplaces no imponen ninguna puerta de revisión o período de espera entre el momento en que se publica una actualización y el momento en que los clientes instalados la descargan.
La comprobación en sí no tiene un único intervalo fijo. Hay un temporizador de respaldo de 12 horas ES extensionsWorkbenchService.ts (1 hora en Insiders con una actualización de producto pendiente), una verificación inmediata al inicio una vez que el entorno de trabajo está inactivo, y varios disparadores basados en eventos (verificación de actualización de producto, cambio de política de lista de permitidos, conexión pasando de medida a no medida, el interruptor de verificación automática se activa). Además de todo eso, existe una ruta separada que detecta las actualizaciones como un efecto secundario de cualquier otra interacción con el marketplace. Cuando VS Code consulta la galería por cualquier motivo (barra lateral de Extensiones visible, búsqueda en el marketplace, avisos de recomendación, subsistemas en segundo plano que obtienen metadatos de la galería), este sincroniza el resultado con las extensiones instaladas y, si alguna está ahora desactualizada, dispara eventuallyAutoUpdateExtensions, que instala a través de un retardador limitado a 1 segundo. Con extensions.autoUpdate activado (por defecto), la instalación se realiza en segundo plano sin aviso.
La ventana de dieciocho minutos en Visual Studio Marketplace detectó cualquier editor en ejecución que realizara una interacción con la galería relacionada con el listado de Nx Console durante esos minutos: barra lateral visible, búsqueda en el marketplace, búsqueda de recomendaciones o cualquiera de los subsistemas en segundo plano que obtienen metadatos de la galería. A través de zonas horarias y horas de trabajo, en una extensión con 2,2 millones de instalaciones y una barra lateral de Extensiones que muchos desarrolladores dejan abierta, esa población es mucho mayor de lo que sugeriría un temporizador periódico por sí solo. Durante nuestras propias pruebas de estas características, hemos visto la actualización automática activarse a los pocos minutos de publicar una nueva versión, lo que coincide con la ruta de sincronización de la galería en lugar del temporizador de 12 horas. La ventana de OpenVSX hizo lo mismo durante aproximadamente treinta y seis minutos.
La cronología de los mantenedores también muestra la brecha de detección que abre la actualización automática. Seis de esos dieciocho minutos pasaron antes de que el mantenedor viera la notificación de carga del marketplace. La actualización automática estaba instalando la versión maliciosa en las máquinas de los usuarios durante esos seis minutos, antes de que cualquier persona del lado del editor pudiera haber sabido cómo actuar.
Por qué esto sigue funcionando
El caso de Nx no es la primera vez que esto le sucede a una extensión de VS Code. En noviembre de 2025, el compromiso de AsyncAPI fue el primer evento de la ola del gusano Shai-Hulud 2.0. Los atacantes habían robado los tokens de publicación de npm y OpenVSX de AsyncAPI, que habían estado en los secretos del repositorio de GitHub durante años, y los usaron para subir paquetes npm maliciosos de AsyncAPI y una versión maliciosa de la extensión AsyncAPI de VS Code en OpenVSX. Al menos un desarrollador informó haber sido infectado a través de la extensión en el propio rastreador de problemas del proyecto antes de que los mantenedores pudieran desaprobar las versiones afectadas. El mismo mecanismo estaba en juego: una credencial robada, utilizada para subir código malicioso a una base de usuarios que se actualiza automáticamente durante un corto período.
Aquí hay varios factores en contra de los defensores:
- Un alto número de instalaciones y las insignias de editor verificado señalan confianza, y la confianza es lo que los atacantes quieren secuestrar. Las extensiones populares ya están en millones de máquinas, por lo que una versión comprometida introduce código malicioso en todas esas instalaciones existentes automáticamente, sin necesidad de ingeniería social contra nuevos usuarios.
- Las extensiones se distribuyen como JavaScript interpretado en lugar de binarios compilados. La carga útil maliciosa de Nx Console fue de 2.777 bytes inyectados en un archivo minificado, que luego obtuvo un dropper ofuscado de 498 KB de un commit huérfano en el repositorio oficial
nrwl/nxrepositorio. EDR no tiene una firma para una diferencia de JavaScript minificado contra una extensión en la que los usuarios ya confían. - Las credenciales de los mantenedores son más fáciles de suplantar (phish) o extraer (scrape) de lo que deberían ser. El caso de Nx comenzó con un token de un compromiso separado, utilizado posteriormente contra un objetivo de confianza. El caso de AsyncAPI comenzó con un token de OpenVSX que había estado en un secreto de repositorio de GitHub durante años.
- La comunidad está siendo rápida en detectar esto, pero dieciocho minutos de distribución automática son suficientes para causar daño, y eso es solo en uno de los dos marketplaces que alojan la extensión.
Una vez que llega a una máquina, el marketplace no puede ayudarte
Los marketplaces tampoco tienen forma de retirar una extensión una vez que ha sido instalada. Retirar el listado detiene las nuevas instalaciones, pero cualquiera que ya haya obtenido la versión maliciosa sigue ejecutándola hasta que actualice a una versión limpia o la desinstale manualmente. La actualización automática eventualmente llevará a los usuarios afectados a la versión parcheada una vez que el mantenedor la publique, pero el marketplace no tiene un interruptor de emergencia ni forma de revertir una instalación más rápido.
El análisis de Wiz Research de la cola larga de Shai-Hulud 2.0 muestra esta dinámica en la práctica. La extensión maliciosa AsyncAPI VS Code (v1.0.1) fue retirada de OpenVSX el 26 de noviembre de 2025, pero el registro revirtió a la versión limpia anterior (v1.0.0). Las copias instaladas en v1.0.1 no vieron ninguna versión más reciente disponible, por lo que la actualización automática nunca se activó. La extensión siguió ejecutándose en las máquinas de los desarrolladores y exfiltrando credenciales durante casi un mes, representando más del 90% de las infecciones de cola larga de la campaña y aproximadamente 100-200 nuevos repositorios comprometidos por día desde el 25 de noviembre hasta el 24 de diciembre. El flujo solo se detuvo cuando AsyncAPI publicó una versión limpia v1.1.0 el 24 de diciembre (después de que Wiz Research les informara del problema el día anterior), momento en el que los IDEs se actualizaron automáticamente a ella y los nuevos compromisos diarios se redujeron a un puñado en cuestión de días.
Microsoft también elimina listados silenciosamente. No hay notificación para los usuarios que instalaron durante la ventana de exposición. Su editor no muestra un mensaje de "puede haber instalado una versión comprometida, por favor, revise su máquina". A menos que estuviera siguiendo las noticias de seguridad el día del incidente, su única señal podría ser que la extensión dejó de aparecer en los resultados de búsqueda del marketplace. El repositorio de Nx Console ya tiene un problema de un desarrollador que pregunta, de buena fe, por qué la extensión había desaparecido del marketplace. La mayoría de los usuarios no se molestarían en preguntar.
El efecto combinado es que la única respuesta efectiva del marketplace es prevenir nuevas instalaciones de una versión maliciosa conocida. Para los desarrolladores que ya descargaron la compilación maliciosa durante la ventana, la limpieza recae completamente en ellos y depende de que se enteren del incidente a través de un canal distinto al propio marketplace.
Qué hacer
Si tenía Nx Console instalado con actualización automática durante esas ventanas el 18 de mayo, la guía del aviso es el punto de partida correcto: rote tokens, secretos, claves SSH y cualquier otra cosa accesible desde la máquina afectada. Cualquiera que haya ejecutado la compilación de OpenVSX está dentro del alcance de la ventana más larga de treinta y seis minutos, en lugar de la de Visual Studio Marketplace.
Para el patrón más amplio, la intervención sencilla es establecer un retraso entre la publicación de una versión y el momento en que se permite su instalación. La solución de Aikido Protección del dispositivo incluye una retención predeterminada de 48 horas en las nuevas versiones de paquetes y extensiones, lo que habría detectado Nx Console (y el reciente tarea duradera compromiso de PyPI) sin que nadie tuviera que identificarlo como malicioso primero. Como particular sin una solución de proveedor, lo más parecido que puedes hacer es desactivar las actualizaciones automáticas de extensiones en VS Code y actualizar según un cronograma deliberado. Es más lento y te quedarás atrás en las versiones legítimas por uno o dos días. Ese es el precio de no ejecutar el código recién publicado de otras personas en tu portátil en el momento en que lo publican.
VS Code ya soporta la superficie de política subyacente para convertir esto en una configuración a nivel de organización. El extensions.allowed La política empresarial permite a los administradores restringir qué editores, extensiones e incluso versiones específicas pueden instalarse en los dispositivos gestionados. Una opción de período de espera adicional (algo como "solo auto-instalar versiones con más de N horas") encajaría en la misma configuración. No hay una buena razón técnica para que no exista ya, y dada la frecuencia con la que ocurren estos incidentes en el marketplace con el que se distribuye, debería existir. Lo mismo ocurre con Cursor y cualquier otro editor basado en VS Code: si ya permites a las organizaciones aplicar una lista blanca, también deberías permitirles aplicar un período de espera.
La historia de GitHub durará semanas porque la víctima es famosa, y la misma maquinaria subyacente seguirá produciendo brechas. Mientras los marketplaces auto-envíen actualizaciones desde cuentas que pueden ser comprometidas de una docena de formas ordinarias, cada extensión popular está a un token robado de convertirse en un gusano.
Aikido Device Protection
Si deseas un período de espera hoy sin esperar a que VS Code o Cursor lo implementen de forma nativa, Aikido Device Protection es lo que recomendamos. Aplica una política configurable de edad mínima (48 horas por defecto) en las instalaciones de paquetes y extensiones a nivel de dispositivo, de modo que la misma política cubre cualquier editor basado en VS Code que utilicen tus desarrolladores.
