El IDE en la pestaña entregó un token de GitHub con un solo clic

El 2 de junio de 2026, el investigador de seguridad Ammar Askar publicó una prueba de concepto de un zero-day en github.dev — la versión en navegador de Visual Studio Code a la que llegas pulsando . en cualquier repositorio de GitHub. Un zero-day es un fallo que el proveedor no ha tenido tiempo de arreglar porque se hizo público en el mismo instante en que se hizo conocido. En este caso, según el relato de Askar, los detalles públicos salieron aproximadamente una hora después de que se notificara a Microsoft. Dijo que había pasado a la divulgación pública completa de sus hallazgos sobre VS Code por frustración con cómo se habían gestionado reportes anteriores al Centro de Respuesta de Seguridad de Microsoft.

Vale la pena ir despacio con la mecánica, porque es un ejemplo limpio de una categoría — no un fallo aislado, sino una forma de ataque que las herramientas de desarrollo basadas en navegador van a seguir produciendo.

Un panel de previsualización no debería ser una rampa de lanzamiento.

Los editores de código renderizan mucho contenido no confiable. Un archivo Markdown que abriste obtiene una previsualización renderizada. Un notebook de Jupyter muestra su salida. Estas previsualizaciones corren dentro de un webview — un mini-navegador en sandbox embebido en el editor, deliberadamente aislado de los propios privilegios del editor para que un README malicioso no pueda simplemente apoderarse de tu máquina.

Ese muro es todo el propósito. El exploit de Askar lo saltó.

El webview habla con el editor principal a través de un canal de paso de mensajes — una tubería estrecha que los dos lados usan para coordinarse. Abusando de ese canal, el JavaScript malicioso corriendo en el webview no confiable podía simular pulsaciones de teclas — eventos keydown sintéticos — en la ventana principal del editor. Las pulsaciones que eligió fueron Ctrl+Shift+P, el atajo que abre la Paleta de Comandos, el cuadro de texto desde el que VS Code puede ejecutar esencialmente cualquier comando que conozca.

A partir de ahí el ataque usó una característica legítima contra sí misma. VS Code soporta extensiones locales de workspace: extensiones colocadas en la carpeta .vscode/extensions de un proyecto, pensadas para que un repositorio pueda traer su propio tooling. Como un repositorio malicioso controla sus propios archivos, puede traer su propia extensión — y el aviso de confianza que normalmente pregunta «¿de verdad quieres ejecutar el código de este editor?» se sorteó creando keybindings personalizados en el package.json de la extensión. El diálogo de confianza del editor, el único punto de control humano de la cadena, nunca apareció.

El premio no era el repo que abriste.

La carga útil de esta cadena es un token. github.dev te conecta con GitHub y guarda un token OAuth — una credencial que el navegador presenta a los servidores de GitHub para probar que actúa en tu nombre. El sentido de OAuth es que el token puede tener ámbito acotado: una app solo debería obtener el acceso estrecho que necesita.

Este token no era estrecho. Como lo expresó Askar, el token «no está acotado al repo concreto con el que interactuaste, lo que significa que tiene acceso total a cada otro repo al que tú tengas acceso» — lectura y escritura, incluyendo repositorios privados. Así que el atacante no obtuvo el proyecto público en el que hiciste clic. Obtuvo una llave a todo lo que tu cuenta puede alcanzar: tus repos privados, los repos privados de tu empleador si tienes acceso, las deploy keys y los secretos que descansan en esos repos, el código fuente que nunca le has mostrado a nadie. La prueba de concepto lo usó para enumerar los repositorios privados de la víctima — una lista que, para la mayoría de desarrolladores en activo, es en sí misma sensible.

Esta es la parte que se generaliza. Los IDE basados en navegador y los entornos de desarrollo en la nube son convenientes precisamente porque llevan tus credenciales por ti. github.dev guarda un token de GitHub. Un IDE en la nube guarda un token de nube. Un asistente de codificación agéntico corriendo en una pestaña del navegador guarda lo que necesite para empujar código y llamar a APIs. Cada uno de esos es un secreto de alto valor a un solo escape-de-sandbox de distancia de una página web que tú no escribiste.

La parte honesta: ¿está arreglado?

Dos reportes, dos imágenes diferentes, y la brecha importa.

BleepingComputer, al momento de escribir esto, describió el problema como sin parche oficial y sin CVE asignado, y ofreció una solución manual: borra las cookies y los datos locales del sitio de github.dev para que reaparezca la advertencia inicial de inicio de sesión.

The Hacker News recogió declaraciones de ingenieros de Microsoft. Alexandru Dima, Partner Software Engineering Manager, dijo que «este problema no afecta a VS Code Desktop» — el fallo es específico de github.dev alojado en navegador, no de la app que instalas en tu máquina. Microsoft afirmó después que la vulnerabilidad «ha sido mitigada para nuestros servicios y no se requiere acción del cliente», lo que apunta a un cambio del lado del servidor en vez de a un parche cliente que descargas.

No estamos en posición de verificar la mitigación de forma independiente, así que no te diremos que la amenaza terminó. De lo que sí podemos hablar es de dónde cae la explosión cuando una cadena como esta funciona — porque esa es una pregunta de arquitectura, y la arquitectura es la parte que no depende de confiar en un comunicado de prensa.

Dónde corre realmente el IDE.

Aquí está lo que de github.dev nos resulta interesante: el editor entero es una página web. El webview, la Paleta de Comandos, el host de extensiones, el token OAuth — todo vive dentro de una pestaña del navegador. Lo que significa que la pregunta «cuánto daño puede hacer esto» es, por una vez, la misma pregunta que Bromure fue construido para responder sobre cualquier pestaña.

En Bromure, cada pestaña corre dentro de su propia máquina virtual desechable — un invitado Linux de usar y tirar sobre el Mac, sin camino a tus archivos, tu keychain ni tus otras pestañas. Ejecuta github.dev en un perfil Bromure y el token OAuth robado, el webview malicioso y la extensión local de workspace instalada silenciosamente están todos acotados a esa única VM. Cierra la ventana en una sesión no persistente y el mundo en el que vivieron queda borrado: la caché del token, las cookies, la extensión, el invitado entero, desaparecidos.

Dos cosas que esta geometría cambia, y una que no.

Cambia qué puede alcanzar el token. En un navegador convencional, cada sesión de GitHub que tengas comparte un tarro de cookies y un perfil. Un token sustraído de tu pestaña github.dev queda junto a todo lo demás que ese navegador guarda. En Bromure, puedes ejecutar github.dev en su propio perfil — su propia VM, sus propias cookies, su propio almacenamiento — separado de tu banca, tu correo y tus otras identidades de GitHub. El compromiso del perfil de usar y tirar no le da al atacante las cookies de los otros. No están en la misma máquina.

Cambia cuánto dura el punto de apoyo. La jugada más valiosa de esta cadena es la extensión instalada silenciosamente — un punto de apoyo que persiste cada vez que reabres el editor. Contra una sesión desechable, no hay nada a lo que volver. La extensión se instaló en una VM que ya no existe.

Lo que no resuelve.

No hace que el token robado deje de estar robado. Mientras la sesión maliciosa esté viva, el token OAuth es real y el atacante puede usarlo para enumerar y leer tus repositorios privados en tiempo real, desde su propia infraestructura. El aislamiento contiene dónde vive el secreto; no llega a través de internet hasta los servidores de GitHub para revocar una credencial que el atacante ya tiene. Las mitigaciones ahí son las de siempre: tokens de corta duración y ámbito estrechamente acotado, revocar sesiones tras cualquier cosa sospechosa, y un proveedor — Microsoft, aquí — cerrando el escape para que el token nunca sea alcanzable, para empezar.

Vale la pena ser preciso sobre una comparación, porque es fácil confundirla. Bromure no permite instalar extensiones de Chrome en absoluto — ni en sandbox, ni curadas, ni de ninguna tienda. Esa es una postura deliberada de producto: la extensión de navegador es uno de los puntos de apoyo más abusados de la web moderna, así que Bromure elimina la categoría. Pero la extensión de esta historia es una extensión de VS Code, instalada por la web app github.dev en su propio editor — algo distinto de una extensión de Chrome, que vive dentro de la página en vez de alrededor de ella. La regla sin-extensiones de Bromure no llega adentro de github.dev para detenerla. Lo que Bromure hace es contener el editor entero, token y extensión y todo, dentro de una VM que puedes tirar.

A menos que no haya token que robar.

Hay una forma más afilada de usar la misma arquitectura, y no cuesta nada: separa quién eres de qué visitas.

La cadena entera existe para alcanzar un secreto — el token OAuth que github.dev guarda porque iniciaste sesión. Ese token solo necesita existir donde trabajas en tu propio código. Así que dale exactamente ese tanto de territorio: un perfil Bromure dedicado, con sesión iniciada en GitHub, donde abres tus repositorios y los repositorios en los que ya confías. El token vive ahí, y el código de los desconocidos no.

Todo lo demás — el repo interesante de un enlace, la prueba de concepto que alguien publicó, la dependencia que estás evaluando — se abre en algún sitio donde no eres nadie: un perfil que nunca inició sesión en GitHub. Lee el código en github.com como un visitante anónimo; si recurres al editor, github.dev sin sesión iniciada no tiene nada que valga la pena entregar. Una sesión no autenticada no puede filtrar un token que no tiene. La cadena de exploit corre, si es que corre, dentro de una VM desechable con los bolsillos vacíos.

Eso cambia la forma de la defensa. La contención limita el daño en el paso cinco, después de que el token es tomado. La separación decapita la cadena en el paso uno: el repositorio malicioso nunca se encuentra con la credencial. La disciplina cabe en una línea — inicia sesión donde trabajas, sé nadie donde merodeas — y los perfiles Bromure la convierten en un hábito de dos iconos en vez de una política de seguridad.

La lección general sobrevive a este fallo en particular. A medida que más del desarrollo se mueve al navegador — IDE en la nube, github.dev, agentes de codificación agénticos que corren en una pestaña y llevan acceso de push — las credenciales que esas herramientas guardan se convierten en un blanco permanente, a un escape-de-webview de distancia de una página que tú no escribiste. La postura defendible no es «confía en el sandbox dentro del IDE». Es asumir que ese sandbox eventualmente filtrará, y disponer las cosas de modo que la página a la que filtra sea a la vez desechable y pobre.

Ejecuta la pestaña arriesgada en su propio mundo — un mundo donde no eres nadie. Cuando algo entre, no hay nada que tomar, y cierras el mundo de todas formas.

Para eso es Bromure. Instálalo, dale a tu propio GitHub un perfil propio, visita el código de todos los demás como un desconocido, y haz del peor caso una ventana que puedes cerrar.