Visual Studio Code incorporó, en su versión 1.123 (3 de junio de 2026), un retraso de dos horas antes de actualizar automáticamente las extensiones a una versión recién publicada. La medida agrega una capa de protección frente a releases comprometidos: cuando una extensión publica una versión nueva, el auto-update en cada equipo no se aplica hasta dos horas después, dando margen para detectar y revocar un paquete malicioso antes de que llegue a los desarrolladores.
Cómo funciona
El retraso es del lado del cliente y aplica solo al auto-update: la versión nueva queda publicada y visible en el Marketplace de inmediato, lo que se demora es su instalación automática. El usuario puede saltarse la espera con el botón «Update» e instalar al instante, y las instalaciones nuevas tampoco se ven afectadas. Mientras un update está en pausa, la vista de detalles de la extensión explica por qué todavía no se actualizó y a qué hora lo hará.
Hay una excepción importante: las extensiones de publishers de confianza como Microsoft, GitHub y OpenAI se siguen actualizando de inmediato, sin el retraso. El valor de dos horas es fijo y, según la documentación del release, no es configurable.
Qué la motivó: 18 minutos que infectaron a miles
Aunque las notas oficiales no nombran incidentes, el contexto es claro. Dos semanas antes del release, el 18 de mayo de 2026, una versión troyanizada de la extensión Nx Console (más de 2 millones de instalaciones) estuvo viva en el Marketplace apenas 18 minutos y aun así la instalaron miles de usuarios, precisamente por el auto-update inmediato. Robaba credenciales de desarrollador, tokens cloud y secretos de CI/CD. Al día siguiente, GitHub reveló que cerca de 3.800 repositorios internos fueron exfiltrados a partir de ese compromiso, y el 28 de mayo CISA emitió una alerta. Una ventana de dos horas habría dado tiempo a revocar la extensión antes de que el update llegara a los endpoints.
De fondo también está GlassWorm, el primer gusano auto-propagante en extensiones de VS Code, descubierto en octubre de 2025, con oleadas sucesivas que llegaron a abusar de decenas de extensiones en Open VSX a lo largo de 2026. La medida se suma a una tendencia transversal: gestores como npm, pnpm, Bun, Yarn y RubyGems sumaron recientemente sus propios mecanismos de «enfriamiento» para retrasar la instalación de paquetes recién publicados.
Lo que no resuelve
El retraso compra tiempo, pero no detecta nada por sí mismo: si nadie identifica el compromiso en esas dos horas, el update malicioso se distribuye igual. Tampoco protege instalaciones nuevas ni updates manuales, no aplica a Open VSX (el marketplace de forks como VSCodium o Cursor) y deja un punto ciego en los publishers exentos: el caso Nx Console demostró que la cuenta de un publisher grande también puede comprometerse. Críticos señalaron que dos horas puede ser poco —se propusieron 24— y que la falta de configurabilidad limita a las organizaciones que querrían una ventana más amplia.
Una defensa de tiempo, no de fondo
La función reconoce algo incómodo: el auto-update inmediato, pensado para comodidad, se volvió un canal de distribución ideal para ataques de cadena de suministro. Retrasar la instalación es una mitigación sensata y de bajo costo, pero sigue dependiendo de que alguien detecte el problema a tiempo. ¿En tu equipo tienen el auto-update de extensiones activado, o ya lo manejan con versiones fijadas y revisión previa? Te leemos en los comentarios.
Fuentes
- Visual Studio Code — Release Notes v1.123 (Delayed extension auto-updates)
- The Hacker News — VS Code Adds 2-Hour Extension Auto-Update Delay
- CISA — Supply Chain Compromises Impact Nx Console and GitHub Repositories
