No toda ejecución remota comienza cuando la víctima hace clic. En la CVE-2026-70336, un enlace malicioso altera silenciosamente una sesión web de VS Code y deja el disparador preparado en el entorno de la terminal remota. La carga se ejecuta después, cuando el desarrollador lanza un comando rutinario de Node.js. Esta separación entre entrega y ejecución vuelve discreta la cadena y puede hacer que el evento parezca una actividad normal de desarrollo.
El advisory del propio proyecto clasifica la falla como alta, con CVSS 3.1 de 8.8. Las versiones anteriores a 1.132.1 están afectadas. La explotación requiere interacción del usuario, pero el atacante no necesita privilegios previos, la complejidad es baja y puede comprometer confidencialidad, integridad y disponibilidad en el contexto de la cuenta que ejecuta el servidor remoto.
Lo confirmado oficialmente
Microsoft publicó GHSA-fp6w-v29h-43rj el 11 de agosto de 2026 y asoció el caso con la CVE-2026-70336. El escenario descrito es específico: un usuario de code-server es inducido a abrir una URL preparada, la URL altera la sesión y el siguiente comando Node.js iniciado en la terminal ejecuta código controlado por el atacante. El vector oficial es CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H.
- Afectadas: versiones de VS Code anteriores a 1.132.1
- Corregida: versión 1.132.1
- Vector inicial: enlace creado por el atacante y abierto por el usuario
- Disparador de ejecución: un comando Node.js iniciado posteriormente en la terminal remota
- Puntuación oficial: CVSS 3.1 de 8.8, severidad alta
- Interacción necesaria: sí, el usuario debe abrir el enlace
La cadena técnica: de la URL al proceso
Según el advisory, tres fronteras fallaron en secuencia. Opciones privilegiadas de desarrollo de extensiones podían llegar mediante payloads de URL en builds de producción. Valores no confiables del cliente alcanzaban el entorno de la terminal remota. Finalmente, esos valores podían sobrescribir variables usadas para iniciar el extension host. El título del advisory identifica la variable decisiva: NODE_OPTIONS.
# Benign local demonstration of documented Node.js behavior.
# This does not exercise the VS Code vulnerability or use a crafted URL.
printf 'console.log("preloaded before the application")\n' > /tmp/vorvex-node-preload.js
NODE_OPTIONS='--require /tmp/vorvex-node-preload.js' \
node -e 'console.log("application started")'
rm /tmp/vorvex-node-preload.js
# Expected order:
# preloaded before the application
# application startedNode.js documenta que las opciones de NODE_OPTIONS se interpretan antes que las opciones de la línea de comandos. Entre las opciones permitidas está --require, capaz de precargar un módulo. Por lo tanto, si una fuente no confiable controla esa variable en el entorno de la terminal, el siguiente node, npm o herramienta basada en Node puede iniciar con código adicional antes de la tarea esperada. El fragmento anterior solo demuestra este comportamiento oficial en una máquina local; no reproduce la falla de VS Code.
Por qué el navegador no limita el impacto
VS Code for the Web por sí solo se ejecuta dentro del sandbox del navegador y ofrece un entorno de ejecución limitado. Eso cambia cuando la interfaz web se conecta mediante Remote Tunnels o VS Code Server. En este modo, los comandos y las extensiones se ejecutan en la máquina remota. La documentación de Microsoft deja claro que el servidor corre con el mismo usuario utilizado para entrar a la máquina.
Por eso, el impacto no queda dentro de la pestaña. El proceso Node.js nace en el host de desarrollo y hereda el alcance de esa cuenta: código fuente, credenciales presentes en el entorno, tokens de registries, llaves accesibles por el usuario y conectividad interna disponible para la máquina. CVSS mantiene el alcance sin cambios porque la ejecución ocurre dentro de la autoridad del componente y del usuario afectados, no porque el daño sea pequeño.
- Repositorios y cambios locales aún no enviados al control de versiones
- Tokens de npm, Git y servicios de CI accesibles para la cuenta de desarrollo
- Credenciales de nube o archivos kubeconfig presentes en el host remoto
- Acceso de red a bases, paneles y servicios internos alcanzables desde el entorno
- Capacidad de modificar dependencias, scripts de build y artefactos producidos después del compromiso
Cómo probar sin convertir el pentest en phishing
La confirmación más segura comienza por versión y arquitectura, no con el envío de un enlace real. En un pentest autorizado, inventariamos qué equipos usan VS Code en el navegador, qué sesiones alcanzan hosts persistentes y qué identidad ejecuta el servidor. Después verificamos que cada componente en ejecución ya esté en 1.132.1 o posterior. El comportamiento de NODE_OPTIONS puede demostrarse en un laboratorio aislado con el módulo benigno mostrado arriba.
# Run in each authorized VS Code client or server environment.
code --version
# The first line must report 1.132.1 or a later release.
# Also verify the version shown by the active remote session instead of
# assuming that an updated desktop client updated every remote server.
# Read-only triage in exported proxy or browser-navigation logs.
# Results are leads for investigation, not proof of exploitation.
rg -i 'NODE_OPTIONS|NODE_OPTIONS%3D|NODE_OPTIONS%253D' \
exported-vscode-access.log exported-browser-history.txtNo recomendamos enviar la URL de explotación a desarrolladores, ni siquiera como simulación sorpresa. Además del riesgo operativo, el disparador retardado dificulta garantizar cuándo y dónde se ejecutará el código. Si el cliente exige una prueba dinámica de la CVE, debe realizarse con cuenta, servidor, repositorio y credenciales desechables, en un horario acordado y con un módulo cuyo único efecto sea registrar un marcador controlado.
Corrección y contención
La corrección está en la versión 1.132.1. De acuerdo con el advisory, el parche rechaza opciones privilegiadas de desarrollo de extensiones provenientes de payloads de URL en builds de producción, sanitiza valores no confiables del entorno de la terminal remota e impide que valores proporcionados por el cliente sobrescriban variables de bootstrap del extension host. Son tres controles independientes en la misma cadena, un enfoque adecuado para evitar que una sola validación olvidada reabra el camino.
- Actualiza VS Code y los componentes del servidor remoto a 1.132.1 o posterior
- Confirma la versión en la sesión remota activa, no solo en la laptop del desarrollador
- Hasta actualizar, no abras URLs de VS Code Web recibidas de fuentes no confiables
- Restringe el acceso a implementaciones web confiables, según la mitigación oficial
- Cierra sesiones sospechosas y abre una terminal nueva para descartar un entorno heredado
- Si hay indicios de ejecución, trata la cuenta del host como comprometida y rota los secretos accesibles para ella
Qué cambia en la revisión de entornos de desarrollo
Un entorno remoto de desarrollo no es solo una IDE publicada. Es un puente autenticado hacia una máquina capaz de compilar, firmar, acceder a dependencias privadas y comunicarse con la red interna. La prueba debe seguir los datos que cruzan ese puente: parámetros de URL, mensajes del cliente, configuración de extensiones, variables heredadas y procesos hijos.
- Incluye VS Code Server, Remote Tunnels e IDEs web en el inventario de activos críticos
- Prueba si los datos del cliente pueden modificar el entorno de la terminal o las opciones de inicio
- Separa los hosts de desarrollo de las credenciales de producción siempre que sea posible
- Aplica mínimo privilegio a los tokens de package registry, Git, nube y CI
- Recolecta telemetría de creación de procesos y cambios de entorno en los hosts más sensibles
- Trata los enlaces profundos de herramientas de desarrollo como entrada no confiable
La lección de la CVE-2026-70336 es directa: una interfaz en el navegador puede terminar en ejecución en el servidor sin que el usuario vea la transición de confianza. Un pentest que solo mira la página pierde el camino más importante. Es necesario seguir la entrada hasta el entorno heredado por el proceso que realmente ejecuta el código.