Microsoft Edge: 5 bugs de lógica valen US$175.000

Una cadena de cinco bugs de lógica que valió US$175.000

El investigador Orange Tsai, del DEVCORE Research Team, logró escapar del sandbox de Microsoft Edge en Pwn2Own Berlin 2026 encadenando bugs de lógica, sin una sola línea de corrupción de memoria, y se llevó US$175.000 y 17,5 puntos Master of Pwn, según el anuncio de TrendAI Zero Day Initiative. La organización acreditó cuatro bugs de lógica en la cadena; el propio Tsai describe el trabajo completo como cinco bugs y dos funciones de Windows.

Para un founder, la lección no está en el exploit. Está en que los fallos más caros del software moderno ya no viven en el código más complejo, sino en decisiones de diseño que nadie revisó durante años.

¿Cómo se rompe un navegador sin corrupción de memoria?

Un sandbox de navegador es el muro que mantiene el código de una página web dentro del navegador y fuera del resto del sistema. Romperlo y ejecutar un programa es lo que convierte un bug web en control total de la máquina. Las fugas de sandbox casi siempre dependen de corrupción de memoria: desbordamientos, punteros colgantes, uso después de liberar.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Esta cadena no usó nada de eso. Tsai construyó todo con errores de lógica en cómo Edge y Windows manejan funciones ordinarias, y afirma que el exploit completo ocupa menos de 100 líneas de código. El resultado es una primitiva de UXSS (Universal Cross-Site Scripting): la capacidad de ejecutar JavaScript en cualquier sitio, ignorando por completo la Content Security Policy.

Como el ataque arranca desde el propio proceso del navegador, alcanza dominios como google.com que un bug web común no puede tocar. Tsai lo describe como una superficie de ataque nueva, no como un caso aislado.

Las cuatro barreras que cayeron una por una

El punto de partida fue un navigation throttle de Edge para inicios de sesión corporativos con Entra ID (Conditional Access). Al dispararlo, el proceso del navegador iniciaba una navegación que no quedaba atada a la página que la había pedido, así que Edge la asociaba a la pestaña activa en ese momento. Ese desajuste es el primer bug y produce el UXSS.

Hacerlo funcionar sin un solo clic requirió cuatro debilidades más, todas documentadas en el análisis de The Hacker News:

Bypass del origen de confianza. Edge verificaba que la petición viniera de un sitio de Microsoft, pero la comprobación se hacía sobre la URL comprometida del WebContents. Abrir la petición desde una segunda ventana con window.open(...) bastaba para saltarla.
Bypass del bloqueador de popups. Edge mantenía una lista blanca de direcciones codificada de forma fija. Una de ellas abría la ventana sin problema, y desde ahí se navegaba al sitio malicioso.
Inicio de sesión automático. El ataque exigía una víctima ya autenticada. La función OneAuth de Edge crea un perfil e inicia sesión sola cuando el usuario visita un sitio de Microsoft, sin que haya configurado nada antes.
Fuga del correo de la víctima. El sitio assets.msn.com devolvía el email del usuario conectado a cualquier web por una configuración CORS mal puesta, lo que permitía leerlo con un simple fetch con credenciales.

De UXSS a ejecución de código: Immersive Reader y un archivo de configuración

Ejecutar JavaScript en cualquier sitio sigue sin ser control de la computadora. Para escapar del sandbox, Tsai usó el modo lectura de Edge, Immersive Reader, que corre bajo un esquema propio read:// que Microsoft dejó fuera de la lista de páginas vetadas para ejecutar scripts.

Desde ahí, la cadena llamó a una función interna de Edge pensada para comprimir registros de diagnóstico y la abusó para escribir un archivo con nombre y contenido elegidos por el atacante en cualquier parte del disco. Ese arbitrary file write se convierte en ejecución de código en dos pasos: sobrescribir el archivo de configuración que define qué sitios pueden lanzar qué manejadores de protocolo, y reiniciar Edge para que lo lea.

Después lanza un enlace telnet://. Como Windows no incluye un programa telnet por defecto, lo busca en las carpetas del PATH, y una de esas carpetas es escribible por un usuario sin privilegios. Ahí es donde queda el ejecutable plantado.

¿Qué significa esto para tu startup?

La conclusión práctica de Tsai es incómoda y útil a la vez: en los bugs de lógica, la parte difícil es encontrarlos, y una vez que los tienes, encadenarlos es lo más fácil. Eso invierte el modelo mental con el que la mayoría de los equipos prioriza seguridad. Se dedica presupuesto a fuzzing y análisis de memoria, mientras las listas blancas codificadas, las comprobaciones de origen mal hechas y las configuraciones CORS quedan sin revisar porque "son código simple".

Tsai también plantea un punto de mercado: en la era de los LLM, la superficie de ataque es el nuevo zero-day. Su cadena se construyó a mano en unos dos meses, sin usar IA, y ganó el Pwnie Award 2026 a Epic Achievement. No es un argumento contra la IA, sino sobre dónde sigue aportando más el juicio humano: decidir qué mirar.

Hay un dato que baja la alarma para el usuario final. The Hacker News reporta que Microsoft publicó el parche el 15 de mayo, un día después del concurso, en Edge Stable 148.0.3967.70, con tres correcciones específicas registradas como CVE-2026-45492, CVE-2026-45494 y CVE-2026-45495. Las dos primeras están puntuadas en 5,4 sobre 10, una nota media que refleja cada bug por separado y no la cadena completa. No hay evidencia de explotación en el mundo real y los registros públicos de CVE marcan la explotación como inexistente.

Acciones concretas para tu equipo

Verifica la versión de Edge. Si tu equipo o tus usuarios están en una build anterior a 148.0.3967.70, la actualización cierra esta cadena por completo. En un navegador con actualizaciones automáticas ya está resuelto y no hace falta ninguna acción extra.
Audita tus propias listas blancas. Revisa cualquier allowlist codificada de forma fija en tu producto: orígenes de confianza, dominios permitidos para popups, esquemas de URL habilitados. Este caso muestra que una entrada olvidada en una lista de conveniencia se convierte en un bypass completo.
Revisa la configuración CORS de tus endpoints. Un endpoint que devuelve datos del usuario autenticado sin validar el origen es suficiente para filtrar identidad. Es una línea de configuración, no un bug complejo, y es exactamente el tipo de fallo que este ataque explotó.
No asumas que "lógica simple" es "lógica segura". Cuando priorices revisiones de seguridad, incluye los flujos de negocio: inicios de sesión guiados, redirecciones, cambios de perfil. Ahí es donde este investigador encontró el punto de entrada.