Un investigador de DEVCORE logró escapar del aislamiento de Microsoft Edge y ejecutar código en Windows sin recurrir a la corrupción de memoria. Microsoft corrigió las vulnerabilidades en mayo, pero la investigación revela hasta dónde puede llegar una cadena de errores aparentemente menores.
Una página web maliciosa puede convertirse en una puerta de entrada al ordenador sin explotar los fallos de memoria que suelen protagonizar los ataques contra navegadores. Eso es lo que demostró Orange Tsai, investigador de seguridad de DEVCORE, al encadenar varios errores lógicos de Microsoft Edge y Windows para superar las protecciones del navegador y ejecutar código en el sistema.
La técnica le permitió ganar 175 000 dólares en el concurso de ciberseguridad Pwn2Own Berlín, celebrado en mayo de 2026. El investigador publicó los detalles de su trabajo el 28 de octubre de 2026, cinco meses después de la competición. Según la información difundida por The Hacker News, Microsoft corrigió los errores de Edge al día siguiente del concurso, por lo que las versiones actualizadas ya cuentan con las correcciones correspondientes.
El hallazgo destaca por una característica poco habitual: la cadena de ataque no necesitó corromper la memoria. En su lugar, aprovechó decisiones de diseño, comprobaciones insuficientes y comportamientos inesperados en funciones legítimas del navegador y del sistema operativo.
Tsai sostiene que el exploit completo ocupa menos de 100 líneas de código. La cifra ilustra una de las dificultades de la ciberseguridad moderna: un ataque sofisticado no siempre necesita una gran cantidad de código, sino encontrar la forma de conectar varios fallos que, por separado, pueden parecer poco relevantes.
Qué descubrió Orange Tsai en Microsoft Edge
La investigación demuestra cómo una sucesión de errores lógicos puede transformar una navegación web en una vía para ejecutar código fuera del entorno protegido del navegador.
Los navegadores modernos utilizan un sandbox o entorno aislado para limitar lo que puede hacer una página web. Este mecanismo busca impedir que el código de un sitio acceda libremente a los archivos, procesos y recursos del resto del ordenador.
Sin embargo, el aislamiento depende de que las distintas capas de seguridad funcionen correctamente y se comuniquen entre sí de manera coherente. Si una función del navegador inicia una operación con permisos o asociaciones inesperadas, el atacante puede intentar aprovechar esa discrepancia para saltarse las restricciones previstas.
En el caso presentado por Tsai, la cadena comenzaba con una función empresarial de Edge relacionada con la limitación de navegación mediante acceso condicional. A partir de ese punto, el investigador encadenó varios errores hasta conseguir ejecutar código en Windows.
El ataque no se basaba en una única vulnerabilidad milagrosa. Su eficacia procedía de la combinación de diferentes debilidades, cada una de las cuales permitía avanzar un paso más.
El primer fallo: una navegación que Edge asociaba a la pestaña equivocada
La cadena comenzaba con una función diseñada para gestionar determinadas condiciones de acceso en entornos empresariales.
Según la explicación publicada por Tsai, al activar esa función, el propio proceso del navegador iniciaba una nueva navegación que no quedaba vinculada correctamente a la página que la había solicitado. Como consecuencia, Edge podía asociar esa navegación a otra pestaña que estuviera abierta.
La discrepancia permitía que un sitio web provocara la ejecución de JavaScript en el contexto de otro sitio. Esta técnica se conoce como Universal Cross-Site Scripting (UXSS), o secuencias de comandos entre sitios universales.
El problema es relevante porque los navegadores aplican la política del mismo origen para separar los datos y las operaciones de páginas pertenecientes a sitios distintos. En condiciones normales, una página no debería poder acceder libremente a la información de otra solo porque el usuario tenga ambas abiertas.
Un fallo UXSS puede romper esa separación y permitir que un sitio ejecute código en el contexto de otro. En función de las condiciones y los permisos disponibles, esto puede exponer datos que normalmente estarían protegidos por las restricciones entre sitios.
Tsai describió el resultado como una nueva superficie de ataque, no simplemente como un error aislado de navegación.
Cómo sorteó las comprobaciones y el bloqueador de ventanas emergentes
El primer fallo no bastaba para completar el ataque sin interacción adicional. El investigador necesitó encadenar otras cuatro vulnerabilidades o debilidades para construir una secuencia que funcionara sin que la víctima tuviera que hacer clic en cada paso.
Una de las barreras era una comprobación que verificaba si la solicitud procedía de un sitio web de Microsoft considerado de confianza. Tsai consiguió sortearla al abrir la solicitud en una segunda ventana.
Esa maniobra se encontró con otra protección: el bloqueador de ventanas emergentes de Edge. El navegador debía impedir que una página abriera ventanas no autorizadas, pero disponía de una lista predefinida de direcciones permitidas. Una de ellas permitía abrir la ventana utilizada en la cadena de ataque.
El episodio muestra una dificultad recurrente en el diseño de seguridad: una excepción legítima puede convertirse en una vía de entrada cuando se combina con otros fallos. Una lista de sitios permitidos puede ser útil para evitar interrupciones en funciones de confianza, pero su eficacia depende de que las excepciones se limiten y se apliquen correctamente.
El ataque también requería que la víctima tuviera una sesión iniciada. La función de inicio de sesión automático de Edge podía proporcionar esa condición cuando el usuario visitaba un sitio de Microsoft.
Después, la cadena leía la dirección de correo electrónico de la víctima desde assets.msn.com, un sitio que, según la investigación, podía redirigir la información a cualquier página debido a una configuración incorrecta de origen cruzado.
La combinación de estos elementos permitió superar varias barreras que, consideradas de manera independiente, estaban destinadas a limitar el comportamiento de una página web.
El Lector Inmersivo abrió otra vía dentro del navegador
Incluso después de lograr la ejecución universal de JavaScript, todavía quedaba un obstáculo: ejecutar código en el ordenador no es lo mismo que conseguir que Windows ejecute un programa controlado por el atacante.
Para avanzar, Tsai recurrió al modo de lectura de Microsoft Edge, conocido como Lector Inmersivo. Esta función permite mostrar el contenido de una página en un formato más sencillo para facilitar la lectura.
El modo utiliza una dirección interna con el esquema personalizado read://. Según la investigación, Microsoft había omitido esa dirección de la lista de páginas en las que se prohíbe ejecutar scripts.
La cadena de ataque aprovechó esa diferencia para acceder a una función interna de Edge diseñada para comprimir registros de diagnóstico. Manipulada de una forma concreta, esa función permitía escribir en el disco un archivo cuyo nombre y contenido elegía el atacante.
El paso es especialmente importante porque conecta una vulnerabilidad del navegador con una operación sobre el sistema de archivos. La escritura de un archivo no implica automáticamente la ejecución de código, pero puede convertirse en un paso decisivo si el atacante consigue que otra función legítima lo cargue o lo ejecute.
De escribir un archivo a ejecutar código en Windows
La fase final aprovechaba el comportamiento de Windows al gestionar determinados controladores de protocolo.
Según la explicación de Tsai, el ataque modificaba un archivo de configuración que controlaba qué sitios web podían iniciar determinados protocolos. Después, reiniciaba Edge para que el navegador leyera la configuración modificada.
A continuación, la cadena iniciaba un enlace con el protocolo telnet://. Como Windows no incluye necesariamente un programa Telnet instalado de forma predeterminada, el sistema podía buscar un ejecutable con ese nombre en las ubicaciones definidas por la ruta de búsqueda del sistema.
La investigación describe cómo el atacante aprovechaba ese comportamiento para lograr que Windows ejecutara una copia del programa colocada en una carpeta en la que un usuario con pocos privilegios podía escribir.
El resultado era la ejecución de código fuera del sandbox del navegador. La cadena había pasado de una página web a una operación capaz de activar un programa en el sistema operativo.
Este detalle no significa que cualquier página pueda controlar cualquier ordenador Windows. El ataque dependía de una combinación específica de errores, condiciones previas y comportamientos del navegador y del sistema. Precisamente por eso, la cadena debe entenderse como una demostración técnica de investigación y no como una prueba de que todos los equipos estuvieran expuestos de la misma forma.
Cinco elementos que hicieron posible la cadena
La investigación de Tsai permite identificar varios componentes que, combinados, hicieron viable el ataque:
- Error de asociación de navegación: Edge podía vincular una navegación iniciada por el propio navegador con una pestaña distinta de la que la había solicitado.
- Evasión de comprobaciones de confianza: la apertura de una segunda ventana permitió sortear una verificación relacionada con sitios de Microsoft.
- Excepción en el bloqueador de ventanas emergentes: una dirección incluida en una lista de sitios permitidos facilitó la apertura de la ventana.
- Configuración de origen cruzado: la lectura de datos desde assets.msn.com se benefició de una configuración que permitía redirigir información a otros sitios.
- Escritura y ejecución de archivos: una función interna del navegador permitió escribir un archivo, mientras que el comportamiento de Windows con el protocolo Telnet facilitó el paso final.
La relevancia de la demostración reside en la interacción entre los fallos, no en que cada uno de ellos proporcionara por sí solo el control completo del sistema.
Microsoft corrigió las vulnerabilidades en mayo de 2026
Microsoft publicó las correcciones el 15 de mayo de 2026, un día después de la competición, mediante la versión estable Microsoft Edge 148.0.3967.70, según las notas de seguridad citadas en la información original.
La actualización incluía tres correcciones específicas para Edge, identificadas como:
- CVE-2026-45492.
- CVE-2026-45494.
- CVE-2026-45495.
Los registros citados calificaban dos de los errores con una puntuación de 5,4 sobre 10. Esa valoración corresponde a vulnerabilidades individuales y no debe confundirse con una puntuación de riesgo de toda la cadena que permitió ejecutar código.
Este matiz importa: una evaluación de una vulnerabilidad aislada no refleja necesariamente las consecuencias de combinarla con otras debilidades. El riesgo práctico puede cambiar cuando varios errores se encadenan y permiten superar distintas capas de protección.
DEVCORE afirmó que Microsoft solucionó los problemas en menos de 24 horas desde su divulgación durante el concurso. La publicación de las correcciones significa que la demostración no debe presentarse como una vulnerabilidad sin parchear que siga afectando a los usuarios de Edge actualizado.
¿Existe constancia de ataques contra usuarios reales?
La información publicada describe una demostración realizada en Pwn2Own Berlín, una competición en la que investigadores ponen a prueba productos tecnológicos bajo condiciones controladas y comunican los fallos encontrados a sus fabricantes.
No hay pruebas en la información proporcionada de que esta cadena se haya utilizado contra usuarios reales. Tampoco debe confundirse la ausencia de una entrada pública de CVE que describa la cadena completa con una prueba de que el ataque fuera imposible: los registros de vulnerabilidades pueden documentar componentes concretos sin reflejar cada combinación técnica descubierta durante una investigación.
La conclusión prudente es que se trató de una cadena de explotación demostrada en un entorno de competición y posteriormente corregida por Microsoft. Las fuentes citadas no acreditan una campaña criminal que la haya utilizado contra el público.
Esta distinción evita generar alarma innecesaria, pero no resta valor al hallazgo. Las demostraciones controladas permiten descubrir problemas antes de que puedan ser aprovechados por actores maliciosos.
Por qué los fallos lógicos pueden ser tan peligrosos
Las vulnerabilidades de memoria —como los desbordamientos de búfer o los errores de uso de memoria— han ocupado durante años un lugar central en la seguridad de los navegadores. Sin embargo, los errores lógicos también pueden comprometer sistemas complejos cuando alteran el orden de las operaciones, las comprobaciones de permisos o las asociaciones entre componentes.
Un fallo lógico aparece cuando un programa realiza una operación que no debería realizar, aunque el código se ejecute sin corromper la memoria. Puede tratarse de una comprobación que no se aplica en todos los casos, una excepción demasiado amplia o una función que interpreta de manera incorrecta el contexto de una solicitud.
El problema se agrava cuando el software integra numerosas funciones, como autenticación empresarial, ventanas emergentes, modos de lectura, protocolos personalizados y herramientas de diagnóstico. Cada componente puede funcionar aparentemente como se diseñó, pero su interacción puede producir un resultado no previsto.
La investigación de Tsai subraya que la seguridad depende tanto de la corrección de cada componente como de la forma en que todos se relacionan. Un sistema puede incorporar múltiples protecciones y seguir siendo vulnerable si una cadena de errores permite atravesarlas una a una.
Dos meses de investigación sin ayuda de inteligencia artificial
Tsai explicó que construyó la cadena manualmente durante aproximadamente dos meses, sin utilizar inteligencia artificial para desarrollar el exploit.
El investigador presentó el trabajo como un ejemplo de la importancia de la creatividad y del análisis humano en la búsqueda de vulnerabilidades. Su planteamiento es que encontrar errores lógicos y comprender cómo pueden conectarse exige investigar el comportamiento real del software, identificar supuestos incorrectos y comprobar las consecuencias de cada interacción.
La afirmación no demuestra que la inteligencia artificial carezca de utilidad en ciberseguridad. Sí pone de relieve que, en investigaciones complejas, la automatización no elimina la necesidad de comprender el sistema, formular hipótesis y validar los resultados.
El trabajo también recibió el premio Pwnie 2026 a la Trayectoria Épica, según la información publicada por The Hacker News.
Qué deben hacer los usuarios de Microsoft Edge
Para los usuarios domésticos y las empresas, la recomendación principal es mantener Edge actualizado. La versión citada como solución se publicó en mayo de 2026, por lo que los equipos que hayan recibido las actualizaciones posteriores deberían contar con las correcciones.
Conviene comprobar lo siguiente:
- Actualizar Microsoft Edge desde el apartado de información del navegador y aplicar cualquier actualización pendiente.
- Reiniciar el navegador si la instalación de una actualización lo requiere.
- Mantener Windows actualizado, ya que la seguridad depende de la interacción entre el navegador y el sistema operativo.
- En entornos empresariales, verificar que las políticas de actualización no estén retrasando la instalación de correcciones de seguridad.
No es necesario que el usuario intente reproducir el ataque ni modificar manualmente archivos de configuración para protegerse. La medida esencial es utilizar una versión corregida del navegador y mantener las actualizaciones de seguridad al día.
Una advertencia sobre la complejidad del software moderno
El caso de Microsoft Edge deja una lección para los fabricantes de navegadores: las funciones diseñadas para mejorar la experiencia del usuario o facilitar la administración empresarial también deben evaluarse dentro de posibles cadenas de ataque.
Una lista de direcciones permitidas, una herramienta de diagnóstico o un modo de lectura pueden tener una finalidad legítima. Pero, si se combinan con errores de contexto y permisos, pueden convertirse en piezas de una vía de explotación mucho más grave.
La demostración de Orange Tsai no acredita que Microsoft Edge siga siendo vulnerable a esta cadena después de las correcciones de mayo. Sí muestra que los errores lógicos pueden permitir superar el aislamiento del navegador sin recurrir a la corrupción de memoria y que el análisis de seguridad debe abarcar las interacciones entre funciones aparentemente independientes.
La principal conclusión para los usuarios es sencilla: mantener el navegador actualizado es la medida inmediata más importante. Para los investigadores y fabricantes, el reto es más amplio: detectar no solo los fallos individuales, sino también las combinaciones inesperadas que pueden convertir un error menor en una vía para ejecutar código en todo el sistema.


