Ir al contenido
Cuando hablamos de robo de tokens OAuth en GitHub, no estamos hablando de una contraseña cualquiera ni de un simple aviso técnico para desarrolladores curiosos. Hablamos de una llave digital que, en el peor escenario, puede permitir acceso a repositorios privados, código sensible, configuraciones internas y piezas críticas de un proyecto.
El caso de GitHub.dev y VS Code llamó tanto la atención porque el ataque se resumía en algo inquietantemente simple: bastaba con que una persona abriera un enlace preparado por un atacante para que se pudiera desencadenar una cadena capaz de exponer el token OAuth de GitHub. No hacía falta instalar manualmente un malware tradicional ni caer en una página falsa con aspecto sospechoso. El riesgo estaba dentro de un flujo que muchos equipos de desarrollo consideran normal: abrir código en el navegador.
"A single malicious link click is sufficient to steal a victim’s full-access GitHub OAuth token." — Cloud Security Alliance
Fuente: Cloud Security Alliance.
Nosotros lo vemos como una advertencia clara: las herramientas cómodas también amplían la superficie de ataque. Cuanto más integramos editores, repositorios, extensiones, automatizaciones y servicios cloud, más importante es revisar qué permisos estamos concediendo y durante cuánto tiempo siguen activos.
En este artículo vamos a explicar qué ocurrió, cómo funcionaba el ataque, qué papel tenían GitHub.dev, VS Code, las webviews y los tokens OAuth, y qué medidas podemos tomar para reducir riesgos. También veremos por qué actualizar no basta si seguimos acumulando accesos antiguos, extensiones innecesarias y tokens con permisos demasiado amplios.
Qué pasó con GitHub.dev, VS Code y los tokens OAuth
GitHub.dev es la versión web, ligera y accesible desde el navegador, del entorno de edición basado en Visual Studio Code. Para muchos desarrolladores es tremendamente útil: abrimos un repositorio, cambiamos «github.com» por «github.dev» o usamos la opción correspondiente, y podemos inspeccionar o editar código sin salir del navegador.
El problema apareció cuando el investigador Ammar Askar publicó una vulnerabilidad que permitía aprovechar comportamientos de VS Code web para instalar una extensión maliciosa y robar el token OAuth que GitHub.dev recibe para actuar en nombre del usuario.
"Just by clicking a link, it’s possible for an attacker to steal a GitHub token that can read and write to your repos." — Ammar Askar
Fuente: Ammar Askar.
La parte delicada no era solo que existiera un token. Eso forma parte del funcionamiento normal de muchas integraciones. Lo preocupante era que ese token podía tener acceso más allá del repositorio concreto que se estaba abriendo. En otras palabras: el problema no se limitaba necesariamente al proyecto visible en pantalla.
Por eso este caso no debe entenderse como “una vulnerabilidad más de un editor”. Debemos verlo como un recordatorio de cómo funcionan las cadenas de confianza modernas: navegador, editor, repositorio, extensiones, cuenta de GitHub y permisos se combinan en una misma experiencia. Si una pieza falla, el impacto puede saltar de una herramienta aparentemente aislada a todo el entorno de desarrollo.
Qué es un token OAuth de GitHub y por qué es tan delicado
Un token OAuth de GitHub es una credencial que permite a una aplicación actuar en nombre de un usuario, dentro de los permisos que ese usuario ha autorizado. En la práctica, es una especie de pase temporal o persistente que evita tener que entregar la contraseña directamente a cada herramienta conectada.
OAuth es útil porque permite integrar servicios: editores, sistemas de despliegue, herramientas de análisis, plataformas de CI/CD, gestores de proyectos o aplicaciones internas. El problema aparece cuando esos permisos son demasiado amplios, no se revisan o quedan activos durante más tiempo del necesario.
"When authorizing an OAuth app, you should ensure you trust the application, review who it's developed by, and review the kinds of information the application wants to access." — GitHub Docs
Fuente: GitHub Docs.
La clave es entender que un token no es “menos importante” que una contraseña solo porque no la veamos. Si un atacante consigue un token con acceso de lectura y escritura a repositorios privados, podría leer código, copiar propiedad intelectual, buscar secretos, modificar archivos o preparar cambios maliciosos.
Desde nuestra perspectiva, el error habitual es pensar que la seguridad de GitHub empieza y termina con la contraseña y el doble factor de autenticación. Eso ayuda, por supuesto, pero no cubre todo el escenario. Si una aplicación autorizada conserva acceso amplio, el riesgo sigue ahí aunque la contraseña sea fuerte.
Cómo funcionaba el ataque de un clic en GitHub.dev
El ataque no dependía de una única debilidad aislada, sino de una cadena de comportamientos. Esa cadena combinaba GitHub.dev, el modelo de seguridad de las webviews de VS Code, notebooks de Jupyter, eventos de teclado simulados y la posibilidad de instalar o ejecutar una extensión maliciosa en el entorno adecuado.
La idea general era esta: el atacante preparaba un repositorio o enlace malicioso que la víctima abría en GitHub.dev. A partir de ahí, el contenido podía interactuar con elementos del entorno de VS Code web de una forma que acababa facilitando la instalación de una extensión hostil. Esa extensión era la pieza que podía acceder al token OAuth y enviarlo fuera.
"The vulnerability allows attackers to install malicious VS Code extensions that steal GitHub OAuth tokens when they are passed to GitHub.dev." — The Hacker News
Fuente: The Hacker News.
Dicho de forma sencilla: no era el clic en sí lo que robaba el token. El clic abría la puerta a una secuencia automatizada. Esa secuencia aprovechaba que el entorno confiaba en ciertos mensajes, eventos y comportamientos internos.
Aquí está la lección importante: cuando trabajamos en herramientas de desarrollo, muchas acciones parecen técnicas e inocentes. Abrir un notebook, previsualizar contenido o cargar una extensión puede formar parte del día a día. Pero si esas acciones se encadenan con permisos sensibles, el resultado puede ser grave.
¿Afectaba a GitHub.dev, VS Code Desktop o ambos?
El escenario más directo era GitHub.dev, porque funciona en el navegador y recibe el token OAuth asociado a la sesión de GitHub. Ahí es donde el ataque resultaba especialmente llamativo: el usuario abría un enlace y el entorno web podía quedar expuesto.
En VS Code Desktop, el panorama era distinto. No hablamos exactamente del mismo flujo de navegador, pero sí de un entorno donde una extensión maliciosa puede tener un impacto todavía más serio si llega a ejecutarse. En escritorio, una extensión puede acercarse más al sistema local, a los archivos del equipo y a otras credenciales disponibles.
Por eso conviene no simplificar demasiado. No deberíamos quedarnos con “solo afecta a GitHub.dev” ni con “todo VS Code está roto”. Lo correcto es separar escenarios:
- En GitHub.dev, el riesgo principal estaba en el token OAuth recibido por el entorno web.
- En VS Code Desktop, el peligro se relaciona más con extensiones maliciosas, ejecución local y acceso al entorno del desarrollador.
- En ambos casos, la higiene de extensiones y permisos sigue siendo crítica.
Nosotros lo resumiríamos así: GitHub.dev fue el punto más visible del caso, pero la lección afecta a cualquier equipo que confíe demasiado en integraciones, extensiones y permisos amplios.
Qué podía hacer un atacante con un token OAuth robado
El impacto dependía de los permisos asociados al token y del acceso real del usuario afectado. Pero si ese usuario tenía permisos sobre repositorios privados, organizaciones o proyectos críticos, el riesgo podía escalar rápidamente.
Un token OAuth robado podría permitir acciones como:
- Leer repositorios privados.
- Copiar código propietario.
- Buscar secretos, claves API, tokens internos o archivos de configuración.
- Modificar código.
- Preparar un ataque de cadena de suministro.
- Revisar issues, pull requests o información privada del proyecto.
- Acceder a repositorios de una organización si el usuario tenía permisos suficientes.
"The token is not scoped to the particular repo you interacted with." — The Hacker News
Fuente: The Hacker News.
Esto es especialmente importante para empresas, agencias, SaaS, startups y proveedores tecnológicos. Muchas veces el código privado contiene mucho más que lógica de aplicación: puede incluir infraestructura como código, scripts de despliegue, rutas internas, nombres de servicios, dependencias críticas o referencias a sistemas de producción.
En un proveedor de hosting, por ejemplo, el impacto potencial de unas credenciales mal protegidas no se limita al repositorio. Puede acabar conectando con despliegues, paneles, pipelines, entornos de staging, automatizaciones y servicios cloud. Por eso no debemos tratar los tokens como simples detalles técnicos.
Microsoft corrigió el fallo: qué significa realmente
Según la información publicada tras la divulgación, Microsoft mitigó el problema el 3 de junio de 2026. Esto es importante porque reduce el riesgo directo del vector concreto descrito en el ataque.
"Microsoft says the issue was mitigated for its services on June 3, 2026." — WinBuzzer
Fuente: WinBuzzer.
Ahora bien, que una vulnerabilidad esté mitigada no significa que podamos ignorar el resto del problema. Si ya existían tokens amplios, aplicaciones antiguas, extensiones innecesarias o permisos sin revisar, todo eso sigue formando parte de nuestra superficie de ataque.
Por eso recomendamos no quedarse solo con “ya está parcheado”. La pregunta correcta es: ¿qué accesos tenemos activos ahora mismo y cuáles son realmente necesarios?
Actualizar es el primer paso. Auditar es el segundo. Reducir permisos es el tercero. Y repetir este proceso de forma periódica es lo que convierte una reacción puntual en una práctica de seguridad sostenible.
Qué hacer ahora para proteger los tokens OAuth de GitHub
La protección no pasa por una única medida mágica. Pasa por reducir privilegios, revisar accesos y controlar mejor el entorno de desarrollo.
Revisar aplicaciones OAuth autorizadas
Debemos entrar en la configuración de GitHub y revisar qué aplicaciones OAuth tienen acceso a nuestra cuenta. Si hay herramientas que no reconocemos, que no usamos desde hace tiempo o que tienen permisos excesivos, lo prudente es revocarlas.
"Review the tokens that have access to your account. For those that you don't recognize or that are out-of-date, click Revoke." — GitHub Docs
Fuente: GitHub Docs.
Ruta recomendada en GitHub:
Settings → Applications → Authorized OAuth Apps
Ahí podemos revisar y revocar accesos.
Revisar GitHub Apps autorizadas
Además de OAuth Apps, también conviene revisar las GitHub Apps autorizadas. Algunas pueden actuar en nuestro nombre, y otras pueden tener permisos instalados en organizaciones o repositorios concretos.
"You can review the GitHub Apps that you have authorized, and you can revoke your authorization." — GitHub Docs
Auditar extensiones de VS Code
Las extensiones son comodísimas, pero también son una vía de riesgo. Deberíamos revisar:
- Qué extensiones tenemos instaladas.
- Quién las publica.
- Cuándo se actualizaron por última vez.
- Qué permisos o capacidades requieren.
- Si realmente las usamos.
- Si existen alternativas oficiales o más mantenidas.
En equipos, conviene crear una lista de extensiones permitidas y bloquear o desaconsejar el resto.
Limpiar sesiones y datos del navegador
Si usamos GitHub.dev con frecuencia, tiene sentido cerrar sesiones, limpiar datos del sitio y volver a autenticar de forma controlada. No es una solución universal, pero ayuda a reducir residuos de sesión y credenciales en escenarios sospechosos.
Aplicar mínimo privilegio
El principio es sencillo: cada herramienta debe tener solo el acceso que necesita, durante el tiempo que lo necesita. Si una aplicación solo debe leer un repositorio, no debería poder escribir en todos. Si una integración ya no se usa, no debería seguir autorizada.
Revisar secretos en repositorios
Después de un posible incidente, no basta con revocar tokens OAuth. También debemos revisar si había secretos expuestos dentro de los repositorios: claves API, tokens de despliegue, credenciales de bases de datos, archivos «.env», configuraciones de CI/CD o credenciales de proveedores externos.
Checklist rápida si creemos que hemos abierto un enlace malicioso
Si sospechamos que hemos abierto un enlace de GitHub.dev preparado por un atacante, lo peor que podemos hacer es quedarnos mirando el historial del navegador sin actuar. Conviene seguir un proceso claro.
Pasos inmediatos
- Revocar aplicaciones OAuth sospechosas desde GitHub.
- Revisar GitHub Apps autorizadas y eliminar las que no reconozcamos.
- Cerrar sesiones activas de GitHub.
- Cambiar contraseña si hay señales de compromiso.
- Revisar actividad reciente en repositorios, organizaciones y pull requests.
- Rotar secretos que pudieran estar en repositorios afectados.
- Revisar extensiones de VS Code instaladas recientemente.
- Comprobar cambios inesperados en ramas, workflows, releases o dependencias.
- Avisar al equipo si usamos repositorios compartidos.
- Documentar la línea temporal del incidente.
Señales de alerta
Debemos prestar atención a:
- Aplicaciones autorizadas que no recordamos.
- Commits que no hemos hecho.
- Pull requests extrañas.
- Cambios en workflows de GitHub Actions.
- Nuevas claves o secretos creados sin explicación.
- Extensiones desconocidas en VS Code.
- Alertas de acceso desde ubicaciones inusuales.
Medidas para equipos y empresas
Si trabajamos en equipo, la respuesta debe ir más allá de la cuenta individual. Conviene revisar accesos de organización, permisos de colaboradores, secretos compartidos, tokens de despliegue y registros de actividad.
Aquí es donde la seguridad del entorno de hosting también importa. Si nuestros repositorios conectan con despliegues, servidores, paneles o infraestructura, debemos asegurarnos de que un incidente en GitHub no pueda saltar fácilmente a producción.
Lecciones de seguridad para desarrolladores y empresas
Este caso nos deja una idea muy clara: no podemos proteger un proyecto mirando solo el servidor final. La seguridad empieza mucho antes, en el repositorio, en el editor, en las extensiones, en los tokens, en el navegador y en las integraciones que usamos todos los días.
La comodidad de abrir un repositorio en el navegador es fantástica. Pero esa comodidad implica confianza. Y la confianza, en seguridad, siempre debe tener límites.
Nosotros aplicaríamos tres reglas:
- Menos permisos por defecto. Si una herramienta no necesita acceso global, no debe tenerlo.
- Menos extensiones instaladas. Cada extensión añade código de terceros al flujo de trabajo.
- Más revisiones periódicas. Los accesos antiguos son una de las puertas olvidadas más habituales.
También deberíamos hablar más de la cadena de suministro del software. Un token robado no solo permite leer código. En manos equivocadas, puede servir para introducir cambios maliciosos, alterar dependencias, manipular automatizaciones o preparar un ataque que afecte a usuarios finales.
Qué papel tiene el hosting en este tipo de incidentes
Un proveedor de hosting no puede impedir que alguien haga clic en un enlace malicioso dentro de GitHub.dev. Pero sí puede ayudar a que el daño no escale tan fácilmente.
Cuando alojamos proyectos, APIs, paneles, tiendas online o aplicaciones críticas, necesitamos una infraestructura que favorezca buenas prácticas: aislamiento, copias de seguridad, control de accesos, monitorización, soporte técnico y despliegues ordenados.
En Bitralix, entendemos que la seguridad no depende de una sola capa. El repositorio importa, pero también importa dónde y cómo desplegamos. Si un atacante consigue tocar código, debemos tener mecanismos para detectar cambios, restaurar versiones, aislar servicios y reaccionar sin improvisar.
Por eso, cuando revisamos un incidente relacionado con tokens OAuth de GitHub, no deberíamos mirar únicamente GitHub. También deberíamos preguntarnos:
- ¿Qué servidores reciben despliegues desde ese repositorio?
- ¿Hay claves de producción en el código?
- ¿Los entornos de staging y producción están separados?
- ¿Existen copias de seguridad recientes?
- ¿Podemos revertir un despliegue comprometido?
- ¿Tenemos registros suficientes para investigar?
La seguridad real está en la suma de capas. Y el hosting es una de esas capas que más se nota cuando algo falla.
Conclusión: el robo de tokens OAuth en GitHub no es un susto menor
El caso de GitHub.dev y VS Code demuestra que un ataque moderno no siempre empieza con un archivo sospechoso o una contraseña filtrada. A veces empieza con algo tan cotidiano como abrir un enlace en una herramienta que usamos a diario.
El robo de tokens OAuth en GitHub es peligroso porque afecta a una zona muy sensible: los permisos que permiten actuar en nombre de un usuario. Si esos permisos son amplios, antiguos o poco revisados, el impacto puede ir mucho más allá de un repositorio concreto.
La buena noticia es que podemos reducir mucho el riesgo con medidas claras: actualizar herramientas, revisar aplicaciones OAuth, revocar accesos innecesarios, auditar extensiones, aplicar mínimo privilegio, rotar secretos y reforzar la infraestructura donde desplegamos.
No se trata de dejar de usar GitHub.dev, VS Code o integraciones modernas. Se trata de usarlas con cabeza. La productividad es bienvenida, pero no debería venir acompañada de confianza ciega.
Protejamos el código antes de que llegue a producción
En Bitralix podemos ayudarte con soluciones de hosting seguras, estables y preparadas para proyectos profesionales, con soporte cercano y una visión práctica de la seguridad.
Preguntas frecuentes
¿Qué es el robo de tokens OAuth en GitHub?
El robo de tokens OAuth en GitHub ocurre cuando un atacante consigue una credencial OAuth que permite actuar en nombre de un usuario. Dependiendo de los permisos concedidos, ese token puede dar acceso a repositorios, datos privados, acciones de escritura o integraciones conectadas.
¿Cómo podía robarse un token OAuth con un clic en GitHub.dev?
El ataque aprovechaba una cadena de comportamientos en VS Code web y GitHub.dev. La víctima abría un enlace malicioso, y ese flujo podía terminar instalando o ejecutando una extensión hostil capaz de acceder al token OAuth usado por GitHub.dev.
¿La vulnerabilidad de GitHub.dev ya está corregida?
Según fuentes publicadas tras la divulgación, Microsoft mitigó el problema el 3 de junio de 2026. Aun así, recomendamos revisar accesos OAuth, GitHub Apps y extensiones, porque el parche de una vulnerabilidad no elimina permisos antiguos ni tokens ya expuestos.
¿Debemos cambiar la contraseña de GitHub?
Cambiar la contraseña puede ser recomendable si hay señales de compromiso, pero no siempre resuelve el problema por sí sola. Si el riesgo está en tokens OAuth o aplicaciones autorizadas, también debemos revocar accesos, revisar sesiones y comprobar actividad reciente.
¿Cómo revisamos las aplicaciones OAuth autorizadas en GitHub?
Podemos hacerlo desde Settings → Applications → Authorized OAuth Apps. Ahí deberíamos revisar qué aplicaciones tienen acceso a la cuenta y revocar las que no reconozcamos, no usemos o tengan permisos excesivos.
¿Qué diferencia hay entre un token OAuth y un personal access token?
Un token OAuth suele estar asociado a una aplicación autorizada para actuar en nombre del usuario. Un personal access token lo crea normalmente el propio usuario para scripts, integraciones o herramientas. Ambos son credenciales sensibles y deben protegerse con el mismo cuidado.
¿El ataque permitía acceder a repositorios privados?
El riesgo principal era precisamente ese: si el token tenía permisos suficientes, un atacante podía acceder a repositorios privados disponibles para la cuenta afectada. Por eso el caso fue tan relevante para desarrolladores, empresas y equipos con código propietario.
¿Debemos dejar de usar GitHub.dev?
No necesariamente. Pero sí deberíamos usarlo con prudencia, mantener el entorno actualizado, evitar abrir enlaces sospechosos, revisar extensiones y controlar los permisos concedidos a aplicaciones conectadas.
¿Cómo protegemos nuestros repositorios privados de GitHub?
Debemos combinar varias medidas: doble factor de autenticación, revisión de OAuth Apps, revisión de GitHub Apps, mínimo privilegio, rotación de secretos, control de extensiones, protección de ramas, revisión de workflows y monitorización de actividad sospechosa.
¿Qué relación tiene esto con la seguridad del hosting?
Si un repositorio comprometido conecta con despliegues o servidores, el incidente puede saltar a producción. Por eso necesitamos separar entornos, proteger credenciales, revisar automatizaciones y trabajar con una infraestructura de hosting que facilite recuperación, control y estabilidad.
