VSCode-Webview-Escape — warum ein Klick in github.dev Schreib-Zugriff auf sämtliche Repos liefert

TL;DR — die 90-Sekunden-Zusammenfassung

Ein Klick auf einen präparierten github.dev-Link reicht, um den GitHub-OAuth-Token mit Vollzugriff auf alle Repos zu stehlen. Kein Patch verfügbar, Mitigation nur über Browser-Seitendaten-Löschung.

Was ist das Problem?

VSCode rendert Inhalte von Extensions und Features wie Markdown-Previews oder Jupyter-Notebooks in sogenannten Webviews. Technisch sind das <iframe>-Elemente mit einem eigenen Origin (vscode-webview://), der vom Haupt-Origin der Anwendung isoliert ist. Diese Isolation ist die zentrale Sicherheitsgrenze: JavaScript, das innerhalb eines Webviews läuft, kann nicht auf VSCodes interne APIs, die Dateisystem-Schicht oder den Electron-Node.js-Kontext zugreifen. Die Kommunikation zwischen Webview und VSCode-Hauptfenster läuft ausschließlich über die Window.postMessage()-API, einen kontrollierten Nachrichtenkanal ohne direkten DOM-Zugriff.

Das Problem sitzt in der Art, wie VSCode Tastatureingaben über diese Grenze transportiert. Damit Keyboard-Shortcuts wie Ctrl+Shift+P (Command Palette) auch dann funktionieren, wenn der Fokus innerhalb eines Webviews liegt, registriert VSCode im Webview einen keydown-Event-Listener und leitet jeden Tastendruck über postMessage an das Hauptfenster weiter. Das Hauptfenster behandelt die weitergeleiteten Events so, als kämen sie direkt vom Benutzer.

Genau hier liegt der Bruch: JavaScript-Code, der innerhalb des Webviews läuft (und dort durch das Sandbox-Modell eigentlich eingesperrt sein sollte), kann synthetische keydown-Events erzeugen und über denselben postMessage-Kanal an das Hauptfenster schicken. VSCode unterscheidet nicht zwischen echten Tastatureingaben und synthetischen Events aus dem Webview. Damit kann ein Angreifer beliebige Keyboard-Shortcuts im Kontext des VSCode-Hauptfensters auslösen.

Der Sicherheitsforscher Ammar Askar hat daraus eine vollständige Exploit-Kette gebaut. Der Einstiegspunkt ist ein Jupyter-Notebook in einem GitHub-Repository. Jupyter-Notebooks können HTML rendern, einschließlich <img>-Tags mit onerror-Handlern — ein bekannter Weg, JavaScript im Webview-Kontext auszuführen. Von dort aus nutzt der Exploit vier Schritte:

Erstens wartet das Skript, bis VSCode eine Benachrichtigung anzeigt, die zur Installation einer empfohlenen Extension auffordert (das Repository enthält eine .vscode/extensions.json mit der Empfehlung einer lokalen Workspace-Extension). Zweitens simuliert das Skript Ctrl+Shift+A (die Tastenkombination für „Accept Notification Primary Action“), um die Installation zu bestätigen. Drittens wartet es, bis die lokale Extension aktiv ist. Diese Extension bringt ein eigenes Keybinding mit (Ctrl+F1), das den Befehl workbench.extensions.installExtension mit dem Parameter skipPublisherTrust: true auslöst. Viertens simuliert das Skript Ctrl+F1, um eine zweite Extension vom VSCode Marketplace zu installieren, die nun vollen Zugriff auf VSCodes Extension-API hat und den GitHub-OAuth-Token ausliest.

Auf github.dev ist der Angriff besonders wirksam, weil github.com beim Öffnen eines Repositories auf github.dev einen OAuth-Token per POST übergibt, der nicht auf das konkrete Repository beschränkt ist — er hat vollen Lese- und Schreibzugriff auf sämtliche Repos des Nutzers, einschließlich privater. Wer bereits einmal die initialen Anmelde-Dialoge auf github.dev durchgeklickt hat und die Seitendaten nicht gelöscht hat, wird beim Klick auf einen präparierten Link ohne weitere Interaktion kompromittiert.

Auf Desktop-VSCode ist der Angriff ebenfalls möglich, erfordert aber, dass das Opfer das präparierte Repository klont und das Notebook im Editor öffnet. Die Auswirkung dort ist schwerer: statt eines Token-Diebstahls hat der Angreifer über die Extension-API vollen Zugriff auf den Node.js-Kontext, also Remote Code Execution auf dem Entwickler-Rechner.

Der Forscher hat den Bug im Full-Disclosure-Verfahren veröffentlicht, ohne vorherige koordinierte Meldung an Microsofts Security Response Center (MSRC). In seinem Beitrag begründet er das mit früheren negativen Erfahrungen bei der MSRC-Koordination zu VSCode-Bugs: ein früherer Report wurde stillschweigend gefixt, ohne Nennung, und als nicht sicherheitsrelevant eingestuft. Ein Proof-of-Concept ist öffentlich verfügbar.

Wer ist betroffen?

Der Angriffsvektor hat zwei Ausprägungen mit unterschiedlichen Einstiegshürden und Wirkungsradien.

Die Kombination aus 1-Click-Exploit, uneingeschränktem Token-Scope und fehlendem Patch macht den Angriffsvektor über github.dev zum operativ relevanteren der beiden Pfade. Desktop-VSCode ist technisch schwerer, aber in der Wirkung (RCE auf dem Entwickler-Rechner) potenziell gravierender.

Auswirkungen

Was diesen Bug operativ schwer macht, ist nicht die Komplexität des Exploits, sondern die Kombination aus drei Faktoren: die triviale Einstiegshürde (ein Klick), der uneingeschränkte Token-Scope (alle Repos, read+write), und die Tatsache, dass zum Zeitpunkt der Veröffentlichung kein Patch existiert.

Der über github.dev exfiltrierte OAuth-Token ist nicht auf das Repository beschränkt, das der Nutzer gerade betrachtet. Er hat vollen Lese- und Schreibzugriff auf sämtliche Repositories, auf die der GitHub-Account Zugriff hat. In einer typischen DACH-Mittelstands-Konstellation mit drei bis zehn privaten Organisations-Repos und persönlichen Repos des Entwicklers bedeutet das: ein einziger kompromittierter Entwickler-Account exponiert den gesamten Code-Bestand der Organisation.

Schreibzugriff auf Repositories ist in der Supply-Chain-Architektur der kritischste Hebel. Ein Angreifer mit Push-Rechten kann Commits direkt in den main-Branch setzen, Tags manipulieren, GitHub-Actions-Workflow-Dateien verändern, und Release-Artefakte überschreiben. Auf einer TYPO3- oder Sylius-Plattform, deren Deployment-Pipeline an GitHub-Tags oder -Branches hängt, ist das der direkte Pfad in die Produktionsumgebung — nicht über eine Lücke in der Anwendung selbst, sondern über die Lieferkette des Plattform-Codes.

Auf Desktop-VSCode geht die Wirkung über Token-Diebstahl hinaus. Die installierte Extension hat vollen Zugriff auf den Node.js-Kontext des Electron-Prozesses, also Remote Code Execution mit den Rechten des angemeldeten Benutzers: Dateisystem-Zugriff, Netzwerk-Zugriff, Prozess-Spawning, SSH-Key-Exfiltration, Credential-Store-Zugriff. Die klassische „ein Repo klonen und öffnen“-Hürde ist für gezieltes Social Engineering kein ernsthaftes Hindernis. Eine Nachricht im Stil von „Kannst du dir kurz dieses Notebook ansehen?“ reicht in vielen Team-Kontexten.

Der Full-Disclosure-Charakter verschärft die Lage. Der Proof-of-Concept ist öffentlich, reproduzierbar und dokumentiert. Die Zeit zwischen Veröffentlichung und Patch (sofern Microsoft einen liefert) ist das operative Risikofenster. Wer in diesem Fenster einen github.dev-Link aus einer unbekannten Quelle anklickt, ist potenziell kompromittiert.

Mitigation und Sofortmaßnahmen

Solange kein Patch von Microsoft vorliegt, ist die einzige vollständige Mitigation die Beseitigung des persistierten Anmeldezustands auf github.dev. Drei operative Pfade nach Dringlichkeit.

Pfad 1 — Browser-Seitendaten für github.dev löschen (sofort)

In Chrome: URL-Leiste → Schloss-/Info-Icon klicken → „Cookies und Websitedaten“ → „Websitedaten auf dem Gerät verwalten“ → alle Domains unter github.dev löschen (Cookies, Local Storage, IndexedDB, Service Workers).

In Firefox: Einstellungen → Datenschutz & Sicherheit → Cookies und Website-Daten → Website-Daten verwalten → nach „github.dev“ filtern → Ausgewählte entfernen.

In Safari: Einstellungen → Datenschutz → Websitedaten verwalten → nach „github.dev“ suchen → Entfernen.

Nach der Löschung zeigt github.dev beim nächsten Aufruf einen Login-Dialog an. Dieser Dialog unterbricht die automatische Exploit-Kette — der Nutzer kann die Seite verlassen, bevor der Angriff greift. Das ist keine vollständige Absicherung, aber es verwandelt einen 0-Click-Exploit (für Nutzer mit persistiertem Login) in einen Angriff, der eine bewusste Anmeldung erfordert.

Pfad 2 — github.dev-Nutzung vorübergehend einstellen

Bis Microsoft einen Patch liefert: keine github.dev-Links aus externen Quellen anklicken. Für schnelle Code-Reviews auf GitHub statt der .dev-Variante die reguläre github.com-Oberfläche oder die GitHub-Mobile-App nutzen. Wer den vollen Editor braucht: GitHub Codespaces als Alternative evaluieren — Codespaces haben ein anderes Token-Handling, der exakte Schutzgrad gegen diesen spezifischen Exploit ist aber nicht abschließend geklärt.

Pfad 3 — Desktop-VSCode: Jupyter-Notebooks aus unbekannten Repos nicht öffnen

Auf Desktop-VSCode ist der Exploit-Pfad enger: das Opfer muss ein präpariertes Repository klonen und ein Jupyter-Notebook öffnen. Die Mitigation ist organisatorisch. Keine .ipynb-Dateien aus unbekannten oder ungeprüften Repositories öffnen, bis VSCode den Webview-Keydown-Forwarding-Mechanismus patcht. VSCodes Workspace-Trust-Mechanismus schützt hier nicht, weil lokale Workspace-Extensions in vertrauenswürdigen Workspaces installiert werden dürfen und github.dev-Workspaces per Default als vertrauenswürdig eingestuft sind.

Token-Audit im Verdachtsfall

Wer in den letzten Tagen einen github.dev-Link aus einer externen Quelle geöffnet hat und unsicher ist, ob der Link präpariert war:

# GitHub-Audit-Log auf unbekannte OAuth-Token-Nutzung prüfen (persönlicher Account)
# Settings → Developer settings → Personal access tokens → Token-Liste prüfen
# Settings → Applications → Authorized OAuth Apps → unbekannte Apps identifizieren

# Für Organisationen: Audit-Log auf Token-Erstellung und Repo-Zugriffe
gh api /orgs/<org>/audit-log \
  --jq '.[] | select(.action | startswith("oauth_application")) | {action, created_at, actor}'

GitHub-App-Installation-Tokens, die über github.dev ausgestellt werden, haben eine begrenzte Lebensdauer. Der OAuth-Token, den github.com an github.dev per POST übergibt, ist ein längerlebiges Session-Token. Wer den Verdacht einer Kompromittierung hat, sollte alle aktiven OAuth-Sessions auf GitHub revoken: Settings → Sessions → „Revoke all“.

Detection und Prüfung

Drei komplementäre Pfade — einer auf der GitHub-Plattform-Ebene, einer auf dem Entwickler-Rechner, einer auf der Organisations-Ebene.

Pfad 1 — GitHub-Audit-Log auf verdächtige Repo-Zugriffe prüfen

Auf Organisations-Ebene lässt sich über das GitHub-Audit-Log erkennen, ob Tokens für ungewöhnliche Repo-Zugriffe genutzt wurden — insbesondere Zugriffe auf Repos, die der betreffende Nutzer normalerweise nicht über github.dev öffnet:

# Organisations-Audit-Log: Repo-Zugriffe der letzten 72h über die REST-API
gh api "/orgs/<org>/audit-log?phrase=action:repo.access+created:>$(date -u -d '72 hours ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --jq '.[] | {actor: .actor, repo: .repo, action: .action, created_at: ."@timestamp"}'

Speziell zu prüfen: Zugriffe auf Repos, die der Nutzer typischerweise nicht bearbeitet, und Push-Events von Nutzern, die normalerweise nur lesen.

Pfad 2 — Lokale VSCode-Extension-Liste auf unbekannte Installationen prüfen

Auf dem Entwickler-Rechner lässt sich die Extension-Liste auf unerwartete Installationen prüfen:

# Installierte VSCode-Extensions auflisten
code --list-extensions --show-versions

# Auf unbekannte Publisher filtern — bekannte Publisher durchlassen
code --list-extensions | grep -v -E "^(ms-|github\.|redhat\.|esbenp\.|dbaeumer\.)"

Auf github.dev: im Browser-DevTools-Tab (F12) → Application → Local Storage → nach Extension-IDs suchen, die nicht zur eigenen Arbeitsumgebung gehören.

Pfad 3 — Netzwerk-Ebene: Outbound-Verbindungen von github.dev-Tabs

Der Proof-of-Concept exfiltriert den Token über eine HTTP-Anfrage an api.github.com/user/repos. Ein tatsächlicher Angreifer würde den Token an einen eigenen Endpunkt senden. In Browser-DevTools (Netzwerk-Tab) oder über ein Unternehmens-Proxy-Log lassen sich Outbound-Verbindungen von github.dev-Tabs identifizieren, die nicht an github.com-, github.dev- oder vscode-cdn.net-Domains gehen.

Betreiberempfehlung

Die operative Frage ist nicht „betrifft uns das?“ — sie lautet „wie viele unserer Entwickler haben github.dev in den letzten Monaten genutzt und haben die Seitendaten noch im Browser?“. Wer die Antwort nicht kennt, behandelt den Bestand als „potenziell exponiert“ und geht den Audit-Pfad.

Operational Decision Block

• Sofort mitigieren, wenn Entwickler regelmäßig github.dev nutzen und private Organisations-Repos über GitHub verwalten — Seitendaten-Löschung Team-weit kommunizieren, github.dev-Nutzung vorübergehend aussetzen.
• Im 24h-Fenster handeln, wenn das Team github.dev gelegentlich nutzt und der Plattform-Code auf privaten GitHub-Repos liegt — Awareness-Nachricht plus Audit-Log-Stichprobe.
• Wartungsfenster möglich, wenn die Organisation GitHub ausschließlich für öffentliche Repositories nutzt und github.dev nicht aktiv im Einsatz ist.
• Reine Awareness, wenn die Plattform-Entwicklung auf GitLab, Bitbucket oder selbst gehosteten Git-Instanzen läuft — github.dev ist dann kein Angriffsvektor.

Mittelstand

Seitendaten-Löschung für github.dev als Team-Kommunikation an alle Entwickler mit GitHub-Zugriff. Keine technische Infrastruktur-Änderung nötig, die Mitigation ist ein Browser-Handgriff pro Person plus die Disziplin, keine unbekannten github.dev-Links zu öffnen. GitHub-Audit-Log stichprobenartig auf ungewöhnliche Push-Events und Token-Erstellungen der letzten 72 Stunden prüfen. Wenn Plattform-Code (TYPO3-Sitepackages, Sylius-Plugins, Deployment-Manifeste) auf privaten GitHub-Repos liegt: Commit-Historie auf unbekannte Commits prüfen, insbesondere auf Änderungen an .github/workflows/-Dateien. Das wäre der Folge-Pfad einer Token-Exfiltration in die CI-Pipeline.

Enterprise

Zentrale Browser-Policy für github.dev-Seitendaten evaluieren. Chrome Enterprise Policies erlauben das gezielte Löschen von Seitendaten per Domain (CookiesBlockedForUrls für github.dev als Zwischenlösung, bis ein Patch vorliegt). GitHub-Enterprise-Audit-Log auf Organisations-Ebene mit dem Detection-Skript aus der vorherigen Sektion durchlaufen, Zeitfenster auf die letzten 7 Tage ausdehnen. GitHub Codespaces als Alternative zu github.dev evaluieren — Codespaces bieten ein stärker isoliertes Umfeld, allerdings mit höheren Kosten und Infrastruktur-Anforderungen. Zusätzlich: Repository-Branch-Protection-Rules auf allen kritischen Repos verifizieren. Ein gestohlener Token kann nur dann direkt in main pushen, wenn keine Branch-Protection aktiv ist.

Kubernetes-Plattform

Der Angriffsvektor geht über den Browser des Entwicklers, nicht über die Cluster-Infrastruktur. Die Cluster-Plattform ist nur mittelbar betroffen, wenn Deployment-Manifeste oder Helm-Charts auf privaten GitHub-Repos liegen und ein kompromittierter Token genutzt wird, um dort Änderungen zu pushen. GitOps-Stacks (ArgoCD, Flux), die auf GitHub-Repos als Source-of-Truth zeigen, sollten Commit-Signatur-Verifikation (--verify-signatures) aktivieren — ein über einen gestohlenen Token gepushter Commit ohne GPG-Signatur wird dann nicht automatisch deployed.

Deklarative Stacks (NixOS / Talos / Flatcar / Wolfi)

Betrifft die Flake-/Konfiguration-Repos, wenn diese auf GitHub gehostet sind. Die Mitigation ist dieselbe wie auf der Kubernetes-Ebene: Commit-Signatur-Verifikation in der GitOps-Pipeline plus Seitendaten-Löschung bei den Entwicklern mit Push-Zugriff. Nix-Flake-Locks und Wolfi-Package-Manifeste sind besonders sensible Angriffsziele, weil eine Manipulation dort die gesamte Build-Kette beeinflusst.

Fazit

Der VSCode-Webview-Escape ist kein CVSS-Schwergewicht im klassischen Sinne: kein Speicherfehler, keine Authentifizierungs-Umgehung, keine aktiv ausgenutzte Zero-Day in freier Wildbahn. Was den Befund operativ ernst macht, ist die Kombination aus trivialer Einstiegshürde und maximaler Wirkung. Ein Klick auf einen Link, ein OAuth-Token mit vollem Repo-Zugriff, kein Patch, öffentlicher Proof-of-Concept.

Für TYPO3- und Sylius-Plattformbetreiber im DACH-Mittelstand, deren Plattform-Code auf privaten GitHub-Repos liegt, ist die Mitigation ein Browser-Handgriff pro Entwickler plus eine Team-Kommunikation zur Awareness. Das ist operativ wenig Aufwand, aber nur dann wirksam, wenn es tatsächlich durchgeführt wird und nicht als „betrifft uns nicht, wir nutzen das selten“ abgetan wird. Ein einziger Entwickler mit persistiertem github.dev-Login und Push-Zugriff auf das Plattform-Repo reicht als Einstiegspunkt.

Die strukturelle Lehre reicht über diesen einzelnen Bug hinaus. Die Webview-Grenze in VSCode war als Sicherheitsgrenze konzipiert, und für die DOM-Isolation funktioniert sie. Der Bruch liegt in der Annahme, dass weitergeleitete Keyboard-Events keine Sicherheitsrelevanz haben. Das ist dieselbe Klasse von Annahme-Verletzung, die wir bei CVE-2026-45793 (Composer-Token-Leak) gesehen haben: eine Validierungs-Annahme, die jahrelang stabil war, kippt durch eine transparente Änderung an einer Nachbar-Komponente. In beiden Fällen ist nicht die Validierung selbst das Problem, sondern die implizite Vertrauensbeziehung über eine API-Grenze hinweg.

Die Frage lautet nicht, ob Microsoft den Webview-Keydown-Forwarding-Mechanismus patchen wird — das wird mit hoher Wahrscheinlichkeit geschehen. Sie lautet, ob Ihre Plattform-Entwickler in den Stunden und Tagen zwischen Full Disclosure und Patch die Seitendaten gelöscht haben, oder ob die Informationskette zwischen Security-Awareness und Browser-Handgriff an derselben Stelle gerissen ist, an der VSCodes Vertrauensmodell gerissen ist.