Bij browseraanvallen denk je vaak aan geheugenfouten zoals out-of-bounds writes of use-after-free. Toch laat nieuw onderzoek zien dat logic bugs Edge sandbox ook zonder geheugencorruptie kunnen leiden tot serieuze gevolgen: code-uitvoering buiten de beveiligde sandbox, inclusief een universele UXSS-aanpak. Het scenario werd gedemonstreerd in het kader van Pwn2Own en Microsoft heeft de kwetsbaarheden al gepatcht.
De onderzoeker, Orange Tsai van DEVCORE, publiceerde zijn volledige methodiek. Het interessante: de keten is opgebouwd uit een reeks logische fouten in hoe Edge en Windows “normale” functies afhandelen—en pas daarna wordt die logica “aaneengeschakeld” tot een eindresultaat.
Waarom deze aanval zo anders is
Een browser-sandbox is bedoeld als een soort muur: webpagina’s mogen code binnen de browser uitvoeren en niet op het hele systeem. Wanneer een aanvaller die barrière doorbreekt, verschuift het risico van “alleen browser” naar “volledige machine”.
Historisch gezien verlopen sandbox-escapes bijna altijd via geheugenproblemen. In dit geval draait het juist om logische fouten: er is geen sprake van geheugenbeschadiging, maar van inconsistenties en controles die op het verkeerde moment of onder de verkeerde omstandigheden worden toegepast.
Wat levert de keten op: universele UXSS
Het uiteindelijke effect wordt door Tsai beschreven als een universal cross-site scripting (UXSS) primitive. Dat betekent: een manier om JavaScript op vrijwel elke website uit te voeren, met omzeiling van content security policy (CSP) die bedoeld is om dat soort aanvallen juist te verhinderen.
Omdat de start van de keten in het proces van de browser zelf ligt, kan de aanval volgens de onderzoeker doelwitten bereiken die een “gewone” webbug niet zou kunnen aanraken, zoals grote sites (in het artikel wordt google.com genoemd).
De aanval begint bij een Edge-functie voor business sign-ins
De keten start met een Edge-onderdeel dat te maken heeft met business sign-ins: de conditional access navigation throttle. Tsai ontdekt dat het triggeren daarvan een nieuwe navigatie kan starten die niet netjes gekoppeld is aan de pagina die de actie initieerde.
Edge zou die navigatie vervolgens aan een ander open tabblad koppelen. Die mismatch is de eerste schakel die, eenmaal “in de juiste richting geduwd”, uiteindelijk UXSS kan opleveren.
Hoe de onderzoekers controle omzeilden zonder ‘magie’
Naast de eerste logische fout zijn er nog vier zwakke plekken nodig om het geheel werkend te maken en zonder menselijke interactie door te laten lopen. In het Pwn2Own-verhaal komen daarbij verschillende concrete omwegen terug:
- Trusted-source check omzeilen: Edge controleert of een verzoek van een vertrouwde Microsoft-site afkomstig is. Tsai omzeilt dit door het verzoek uit een tweede venster op te bouwen.
- Popup blocker omzeilen: Edge zou een popup normaal moeten blokkeren. Toch gebruikt Edge een hardcoded lijst met adressen waarnaar een popup wél mag openen, waardoor één adres de blokkade doorbreekt.
- Al ingelogde gebruiker vereisen: de aanval werkt alleen als het slachtoffer al is ingelogd. Edge auto-sign-in kan dat effect helpen realiseren wanneer een gebruiker een Microsoft-site bezoekt.
- Misconfiguratie bij cross-origin gegevens: de keten leest het e-mailadres via assets.msn.com. Volgens Tsai kan die informatie vervolgens ook aan elke andere website worden teruggegeven door een configuratieprobleem in cross-origin verwerking.
Een extra nuance uit de publicatie: één stap in de keten herstart de browser. Tsai beschrijft dat als handige “wedstrijd-hulp”, maar niet noodzakelijk voor een real-world aanval.
Sandbox escape via “reading mode” (Immersive Reader)
Nadat de keten UXSS kan bereiken, is het nog niet zo dat de aanvaller direct volledige controle op de computer heeft. Voor echte ontsnapping uit de sandbox gebruikt Tsai Edge’s reading mode, namelijk Immersive Reader.
Die modus draait onder een speciaal read://-adres. Microsoft had dat adres volgens het artikel onbedoeld niet opgenomen in de lijst met pagina’s die géén scripts mogen uitvoeren. Daardoor kan de keten scripts “verder trekken” dan je op basis van normale scriptbeperkingen zou verwachten.
Van JavaScript naar bestandsaanmaak en code-uitvoering
Vanaf Immersive Reader gaat het naar een interne Edge-functie die normaal bedoeld is om diagnostische logs te verpakken. In Tsai’s demonstratie wordt die functie misbruikt om een bestand weg te schrijven met een door de aanvaller gekozen naam en inhoud.
Daarna volgt de omslag naar echte code-uitvoering in twee stappen:
- Configuratiebestand overschrijven dat bepaalt welke websites bepaalde protocolhandlers mogen activeren, gevolgd door een Edge-herstart zodat het systeem dat bestand opnieuw kan lezen.
- Een telnet:// link starten. Windows levert standaard niet altijd een telnet-programma, waardoor het systeem zoekt in de “system path” en een door de aanvaller geplaatste kopie kan uitvoeren in een map die een low-privileged gebruiker kan beschrijven.
Was dit al actief in het wild?
Het onderzoek is gepresenteerd als wedstrijdexploit. Er is in het artikel geen aanwijzing dat de keten al is gebruikt tegen echte gebruikers. Bovendien geven de publieke CVE-vermeldingen aan dat er geen exploitatie wordt gerapporteerd.
Dat neemt niet weg dat de techniek waardevol is om te begrijpen. Het gaat immers om een patroon: logische inconsistenties in beveiligingslogica kunnen een toegangspunt worden om beperkingen te omzeilen.
Microsoft patched het—update Edge
Microsoft heeft de kwetsbaarheden verholpen op de dag na het Pwn2Own-event. Het patchmoment dat in het artikel wordt genoemd: 15 mei, met Edge Stable 148.0.3967.70. De release bevatte drie Edge-specifieke fixes, aangeduid als:
- CVE-2026-45492
- CVE-2026-45494
- CVE-2026-45495
De eerste twee zijn in Microsoft-registraties geclassificeerd als respectievelijk een security feature bypass en een spoofing-bug, beide gericht op versies vóór 148.0.3967.70. In de publicatie wordt ook genoemd dat de afzonderlijke impactscores medium zijn, met de kanttekening dat de keten pas samen het eindresultaat oplevert.
Omdat Edge automatische updates ondersteunt, is de praktische actie simpel: zorg dat je browser up-to-date is. Volgens de publicatie hebben updates met auto-update dit al lang kunnen doorvoeren.
Wat kunt u hiervan meenemen voor uw beveiligingspraktijk?
Zelfs als dit specifieke scenario niet actief in het wild is, is de les breder. Organisaties die browsergebruik faciliteren, kunnen profiteren van dezelfde kernmaatregelen:
- Houd browsers en endpoints actueel (automatische updates zijn hier geen “nice to have”).
- Gebruik gelaagde controles: een CSP of een sandbox alleen is niet genoeg wanneer logische regels verkeerd worden geïnterpreteerd onder uitzonderlijke toestanden.
- Let op account- en sign-in flows: de keten vereist dat een gebruiker al is ingelogd en leunt op auto-sign-in en gegevensuitwisseling tussen sites.
Als u meer wilt lezen over het belang van snelle patching en concrete browser-incidenten, dan is dit artikel mogelijk relevant: Chrome en Firefox updates: patch 200+ kwetsbaarheden.
Voor een bredere blik op het soort ketens dat kan ontstaan wanneer een enkele fout tot meerdere effecten leidt, kunt u ook kijken naar PHP2Shell + kernel-exploit wortelt 25 servers.
Conclusie
De publicatie van DEVCORE laat zien dat logic bugs Edge sandbox—dus zonder geheugenfouten—toch kunnen uitgroeien tot een keten met universele UXSS en uiteindelijk code-uitvoering. Het ging om een Pwn2Own-demonstratie en er is geen bewijs van misbruik in het wild, maar het toont wél hoe belangrijk het is om browsers snel te patchen.
De boodschap is daarmee vooral praktisch: draai Edge op de meest recente versie. Daarmee sluit u de gepubliceerde aanvalsketen af en verkleint u de kans dat vergelijkbare logische bypasses weer effect hebben.
Bron: https://thehackernews.com/2026/10/researcher-reveals-how-logic-bugs-alone.html
