Öffne ein Repository in github.dev, klicke auf einen Link, und ein Editor, der innerhalb eines Browser-Tabs läuft, installierte still eine Erweiterung, las deinen GitHub-OAuth-Token und begann, deine privaten Repositories aufzulisten. Kein Download. Kein „Erlauben“-Button. Die ganze IDE lebt in einer Webseite — was genau der Grund ist, warum der Explosionsradius eine Frage über den Browser ist, nicht über die IDE.

Am 2. Juni 2026 veröffentlichte der Sicherheitsforscher Ammar Askar einen Proof-of-Concept für einen Zero-Day in github.dev — der In-Browser-Version von Visual Studio Code, die du erreichst, indem du auf einem beliebigen GitHub-Repository . drückst. Ein Zero-Day ist ein Bug, für dessen Behebung der Hersteller keine Zeit hatte, weil er im selben Moment öffentlich wurde, in dem er bekannt wurde. In diesem Fall gingen, nach Askars Darstellung, die öffentlichen Details etwa eine Stunde, nachdem Microsoft benachrichtigt worden war, hinaus. Er sagte, er sei aus Frustration darüber, wie frühere Meldungen an Microsofts Security Response Center behandelt worden waren, zur vollständigen Veröffentlichung von VS-Code-Funden übergegangen.

Die Mechanik lohnt es sich, langsam durchzugehen, denn sie ist ein sauberes Beispiel für eine Kategorie — kein einmaliger Bug, sondern eine Angriffsform, die browserbasierte Entwicklungswerkzeuge weiter hervorbringen werden.

Ein Vorschau-Panel soll keine Startrampe sein.

Code-Editoren rendern eine Menge nicht vertrauenswürdiger Inhalte. Eine Markdown-Datei, die du geöffnet hast, bekommt eine gerenderte Vorschau. Ein Jupyter-Notebook zeigt seine Ausgabe. Diese Vorschauen laufen innerhalb einer Webview — eines sandboxed Mini-Browsers, der in den Editor eingebettet ist und bewusst von den eigenen Privilegien des Editors abgeschottet wird, sodass eine bösartige README nicht einfach deinen Rechner übernehmen kann.

Diese Mauer ist der ganze Punkt. Askars Exploit ging über sie hinweg.

Die Webview spricht mit dem Haupteditor über einen Message-Passing-Kanal — eine schmale Leitung, die beide Seiten zur Koordination nutzen. Indem sie diesen Kanal missbrauchte, konnte das bösartige JavaScript, das in der nicht vertrauenswürdigen Webview lief, Tastenanschläge simulieren — synthetische keydown-Events — im Hauptfenster des Editors. Die Tastenanschläge, die es wählte, waren Ctrl+Shift+P, das Kürzel, das die Command Palette öffnet, das Textfeld, von dem aus VS Code im Wesentlichen jeden Befehl ausführen kann, den es kennt.

Von dort nutzte der Angriff ein legitimes Feature gegen sich selbst. VS Code unterstützt lokale Workspace-Erweiterungen: Erweiterungen, die im .vscode/extensions-Ordner eines Projekts liegen, gedacht dafür, dass ein Repository sein eigenes Tooling mitliefern kann. Da ein bösartiges Repository seine eigenen Dateien kontrolliert, kann es seine eigene Erweiterung mitliefern — und der Vertrauens-Prompt, der normalerweise fragt „willst du den Code dieses Publishers wirklich ausführen?“, wurde umgangen, indem im package.json der Erweiterung eigene Keybindings gebastelt wurden. Der Publisher-Vertrauensdialog, der eine menschliche Kontrollpunkt in der Kette, erschien nie.

Die github.dev-Ein-Klick-Kette. Ein Vorschau-Panel (eine sandboxed Webview) steuert den Editor, in dem es lebt: es fälscht einen Ctrl+Shift+P-Tastenanschlag, öffnet die Command Palette und löst eine lokale Workspace-Erweiterung aus, deren eigene Keybindings den Publisher-Vertrauens-Prompt überspringen. Die Erweiterung liest dann den GitHub-OAuth-Token, den die Seite hielt.

Die Beute war nicht das Repo, das du öffnetest.

Die Nutzlast dieser Kette ist ein Token. github.dev meldet dich bei GitHub an und hält einen OAuth-Token — einen Credential, den der Browser GitHubs Servern vorzeigt, um zu beweisen, dass er in deinem Namen handelt. Der Sinn von OAuth ist, dass der Token gescopt werden kann: eine App sollte nur den schmalen Zugriff bekommen, den sie braucht.

Dieser Token war nicht schmal. Wie Askar es formulierte, ist der Token „nicht auf das konkrete Repo gescopt, mit dem du interagiert hast, was bedeutet, dass er vollen Zugriff auf jedes andere Repo hat, auf das du Zugriff hast“ — Lesen und Schreiben, einschließlich privater Repositories. Der Angreifer bekam also nicht das öffentliche Projekt, in das du hineingeklickt hast. Er bekam einen Schlüssel zu allem, was dein Account erreichen kann: deine privaten Repos, die privaten Repos deines Arbeitgebers, falls du Zugriff hast, die Deploy-Keys und Secrets, die in diesen Repos liegen, den Quellcode, den du nie jemandem gezeigt hast. Der Proof-of-Concept nutzte ihn, um die privaten Repositories des Opfers aufzulisten — eine Liste, die für die meisten arbeitenden Entwickler selbst sensibel ist.

Das ist der Teil, der sich verallgemeinert. Browserbasierte IDEs und Cloud-Entwicklungsumgebungen sind bequem genau deshalb, weil sie deine Credentials für dich tragen. github.dev hält einen GitHub-Token. Eine Cloud-IDE hält einen Cloud-Token. Ein agentischer Coding-Assistent, der in einem Browser-Tab läuft, hält, was immer er braucht, um Code zu pushen und APIs aufzurufen. Jeder davon ist ein hochwertiges Secret, das nur einen Sandbox-Ausbruch von einer Webseite entfernt sitzt, die du nicht geschrieben hast.

Der ehrliche Teil: Ist es behoben?

Zwei Berichte, zwei verschiedene Bilder, und die Lücke ist wichtig.

BleepingComputer beschrieb das Problem zum Zeitpunkt des Schreibens als ohne offiziellen Patch und ohne zugewiesene CVE und bot einen manuellen Workaround an: lösche die Cookies und lokalen Site-Daten von github.dev, sodass die anfängliche Anmelde-Warnung wieder erscheint.

The Hacker News führte Stellungnahmen von Microsoft-Ingenieuren. Alexandru Dima, ein Partner Software Engineering Manager, sagte, „dieses Problem betrifft VS Code Desktop nicht“ — der Bug ist spezifisch für das browser-gehostete github.dev, nicht für die App, die du auf deinem Rechner installierst. Microsoft erklärte später, die Schwachstelle „wurde für unsere Dienste entschärft und es ist keine Kundenaktion erforderlich“, was auf eine serverseitige Änderung hindeutet, statt auf einen Client-Patch, den du herunterlädst.

Wir sind nicht in der Lage, die Entschärfung unabhängig zu verifizieren, also werden wir dir nicht sagen, dass die Bedrohung vorbei ist. Worüber wir reden können, ist, wo der Einschlag landet, wenn eine Kette wie diese funktioniert — denn das ist eine Architekturfrage, und die Architektur ist der Teil, der nicht davon abhängt, einer Presseerklärung zu vertrauen.

Wo die IDE tatsächlich läuft.

Hier ist das, was github.dev für uns interessant macht: der ganze Editor ist eine Webseite. Die Webview, die Command Palette, der Extension-Host, der OAuth-Token — all das lebt innerhalb eines Browser-Tabs. Was bedeutet, dass die Frage „wie viel Schaden kann das anrichten“ ausnahmsweise dieselbe Frage ist, die Bromure über jeden Tab zu beantworten gebaut wurde.

In Bromure läuft jeder Tab innerhalb seiner eigenen wegwerfbaren virtuellen Maschine — eines Linux-Gasts zum Wegwerfen auf dem Mac, ohne Pfad zu deinen Dateien, deinem Keychain oder deinen anderen Tabs. Lass github.dev in einem Bromure-Profil laufen, und der gestohlene OAuth-Token, die bösartige Webview und die still installierte lokale Workspace-Erweiterung sind alle auf diese eine VM gescopt. Schließe das Fenster in einer nicht-persistenten Session, und die Welt, in der sie lebten, ist gelöscht: der Token-Cache, die Cookies, die Erweiterung, der ganze Gast, weg.

Derselbe github.dev-Exploit, zwei Browser. Links ein konventioneller Browser: der Tab teilt sich einen Cookie-Jar und ein Profil mit jeder anderen GitHub-Session, die du hast, und der gestohlene Token ist langlebig. Rechts Bromure: der Tab ist eine wegwerfbare VM. Der Token, die Webview und die untergeschobene Erweiterung sind auf ein Profil gescopt, das verworfen wird, wenn du es schließt. Und die schärfste Version ist nicht abgebildet — öffne die Repos von Fremden in einem Profil, das sich nie angemeldet hat, und es gibt überhaupt keinen Token zu stehlen.

Zwei Dinge, die diese Geometrie ändert, und eines, das sie nicht ändert.

Sie ändert, was der Token erreichen kann. In einem konventionellen Browser teilt sich jede GitHub-Session, die du hast, einen Cookie-Jar und ein Profil. Ein Token, der aus deinem github.dev-Tab gehoben wird, sitzt neben allem anderen, was dieser Browser hält. In Bromure kannst du github.dev in seinem eigenen Profil laufen lassen — seiner eigenen VM, seinen eigenen Cookies, seinem eigenen Speicher — getrennt von deinem Banking, deiner E-Mail und deinen anderen GitHub-Identitäten. Die Kompromittierung des Wegwerf-Profils gibt dem Angreifer nicht die Cookies in den anderen. Sie sind nicht in derselben Maschine.

Sie ändert, wie lange der Brückenkopf hält. Der wertvollste Zug in dieser Kette ist die still installierte Erweiterung — ein Brückenkopf, der jedes Mal persistiert, wenn du den Editor erneut öffnest. Gegen eine wegwerfbare Session gibt es nichts, zu dem man zurückkommen könnte. Die Erweiterung wurde in eine VM installiert, die nicht mehr existiert.

Was es nicht löst.

Es macht den gestohlenen Token nicht ungestohlen. Solange die bösartige Session aktiv ist, ist der OAuth-Token echt, und der Angreifer kann ihn nutzen, um deine privaten Repositories in Echtzeit aufzulisten und zu lesen, von seiner eigenen Infrastruktur aus. Isolation enthält, wo das Secret lebt; sie reicht nicht über das Internet zu GitHubs Servern, um einen Credential zu widerrufen, den der Angreifer bereits hält. Die Gegenmaßnahmen dort sind die gewöhnlichen: kurzlebige und eng gescopte Tokens, das Widerrufen von Sessions nach allem Verdächtigen und ein Hersteller — Microsoft, hier — der den Ausbruch schließt, sodass der Token gar nicht erst erreichbar ist.

Es lohnt sich, bei einem Vergleich präzise zu sein, denn es ist leicht, ihn zu verwischen. Bromure erlaubt es überhaupt nicht, Chrome-Erweiterungen zu installieren — nicht sandboxed, nicht kuratiert, nicht aus irgendeinem Store. Das ist eine bewusste Produkthaltung: die Browser-Erweiterung ist einer der am meisten missbrauchten Brückenköpfe im modernen Web, also entfernt Bromure die Kategorie. Aber die Erweiterung in dieser Geschichte ist eine VS Code-Erweiterung, von der github.dev-Web-App in ihren eigenen Editor installiert — eine andere Sache als eine Chrome-Erweiterung, die innerhalb der Seite lebt statt um sie herum. Bromures No-Extensions-Regel reicht nicht ins Innere von github.dev hinein, um es zu stoppen. Was Bromure tut, ist, den ganzen Editor zu enthalten, Token und Erweiterung und alles, innerhalb einer VM, die du wegwerfen kannst.

Es sei denn, es gibt keinen Token zu stehlen.

Es gibt eine schärfere Art, dieselbe Architektur zu nutzen, und sie kostet nichts: trenne wer du bist von was du besuchst.

Die ganze Kette existiert, um ein Secret zu erreichen — den OAuth-Token, den github.dev hält, weil du dich angemeldet hast. Dieser Token muss nur dort existieren, wo du an deinem eigenen Code arbeitest. Also gib ihm genau so viel Territorium: ein dediziertes Bromure-Profil, bei GitHub angemeldet, wo du deine Repositories und die Repositories öffnest, denen du bereits vertraust. Der Token lebt dort, und der Code von Fremden tut es nicht.

Alles andere — das interessante Repo aus einem Link, der Proof-of-Concept, den jemand gepostet hat, die Abhängigkeit, die du evaluierst — wird irgendwo geöffnet, wo du niemand bist: ein Profil, das sich nie bei GitHub angemeldet hat. Lies den Code auf github.com als anonymer Besucher; wenn du nach dem Editor greifst, hat github.dev ohne Anmeldung nichts, was es preisgeben könnte. Eine nicht authentifizierte Session kann keinen Token leaken, den sie nicht hält. Die Exploit-Kette läuft, wenn sie überhaupt läuft, innerhalb einer wegwerfbaren VM mit leeren Taschen.

Das ändert die Form der Verteidigung. Containment begrenzt den Schaden bei Schritt fünf, nachdem der Token genommen wurde. Trennung enthauptet die Kette bei Schritt eins: das bösartige Repository trifft nie auf den Credential. Die Disziplin passt in eine Zeile — sei angemeldet, wo du arbeitest, sei niemand, wo du herumstreifst — und Bromure-Profile machen daraus eine Zwei-Icon-Gewohnheit statt einer Sicherheitsrichtlinie.

Die allgemeine Lehre überlebt diesen einen Bug. Da sich mehr von der Entwicklung in den Browser verlagert — Cloud-IDEs, github.dev, agentische Coding-Agents, die in einem Tab laufen und Push-Zugriff tragen — werden die Credentials, die diese Werkzeuge halten, zu einem stehenden Ziel, einen Webview-Ausbruch von einer Seite entfernt, die du nicht geschrieben hast. Die verteidigbare Haltung ist nicht „vertraue der Sandbox innerhalb der IDE“. Sie ist anzunehmen, dass diese Sandbox irgendwann leckt, und die Dinge so zu arrangieren, dass die Seite, in die sie leckt, sowohl wegwerfbar als auch pleite ist.

Lass den riskanten Tab in seiner eigenen Welt laufen — einer Welt, in der du niemand bist. Wenn etwas hereinkommt, gibt es nichts zu nehmen, und du schließt die Welt sowieso.

Dafür ist Bromure da. Installiere es, gib deinem eigenen GitHub ein eigenes Profil, besuche den Code aller anderen als Fremder und mach den schlimmsten Fall zu einem Fenster, das du schließen kannst.