Ein öffentlich geteilter ChatGPT-Link konnte Angreifer-Code in deiner angemeldeten Sitzung ausführen. Was genau kaputtging, warum das jedes Unternehmen mit KI-Betrieb betrifft und was diese Woche zu tun ist.
Jemand schickt dir einen Link. Er sieht aus wie jede andere geteilte ChatGPT-Unterhaltung, die du je geöffnet hast: dieselbe Domain, dasselbe Layout, ein Chat über ein Diagramm und ein bisschen HTML. Du klickst. Vielleicht klickst du aus Neugier sogar noch auf die kleine Preview-Schaltfläche.
Das war der ganze Angriff. Laut dem Forschungsunternehmen Parameter ließ dieser eine Klick ihren Code in deiner authentifizierten ChatGPT-Sitzung laufen, mit demselben Zugriff wie die echte ChatGPT-Seite. Von dort listete er aktuelle Unterhaltungen auf, öffnete einen privaten Chat, der nie mit jemandem geteilt worden war, und schickte einen Teil davon an einen Server der Forschenden. Ihre eigene Zusammenfassung ist deutlich: Sie konnten jede Aktion im Namen des ChatGPT-Kontos des Opfers ausführen.
Parameter meldete die Lücke am 18. Oktober 2026 über OpenAIs Bug-Bounty-Programm. OpenAI behob sie am 26. Oktober und stufte sie als P1 ein, die schwerste Kategorie. Es gibt keine Hinweise auf einen realen Einsatz, und der Nachweis wurde zwischen den eigenen Konten der Forschenden geführt. Der Patch ist ausgeliefert. Das Muster bleibt.
Es begann mit einem Diagramm und einer Tastatur
Das ist der Teil, den man zweimal lesen sollte, denn er erklärt, warum "wir haben den Bug gepatcht" nie das Ende der Geschichte ist.
ChatGPT kann einen HTML-Block aus einer Unterhaltung über die Preview-Funktion in eine kleine funktionsfähige Webseite verwandeln. Weil diese Seite beliebigen Code enthalten kann, führt OpenAI sie in einem eingeschränkten Frame unter einer anderen Webadresse aus. Für sich genommen hielt diese Trennung: Code in der Vorschau konnte die Hauptseite von ChatGPT nicht lesen.
Die Unterhaltung enthielt außerdem ein ganz normales interaktives Diagramm. Im Hintergrund lud das Diagramm MathLive, eine Bibliothek für Mathematik-Satz. Das Laden tat mehr, als eine Kurve zu zeichnen: Es installierte in der Hauptseite von ChatGPT einen Listener für Nachrichten zur Bildschirmtastatur von MathLive.
Browser nennen diese API postMessage. Man kann sie sich wie einen Briefschlitz zwischen zwei Frames vorstellen, die ansonsten gegeneinander versiegelt sind. Sicher ist das nur, wenn der Empfänger prüft, wer sendet.
Der Listener von MathLive verwendete eine Origin-Richtlinie von none, also eine höfliche Formulierung dafür, dass er Nachrichten von jeder Webadresse akzeptierte. Die akzeptierte Nutzlast aktualisierte das Layout der virtuellen Tastatur, und dieses Layout durfte HTML enthalten. Beim Öffnen der Tastatur fügte die Bibliothek das gelieferte Layout zu einem HTML-String zusammen und wies ihn in der echten ChatGPT-Seite innerHTML zu. Eine Hilfsfunktion namens createHTML sah so aus, als würde sie den Wert bereinigen. Tat sie aber nicht: Sie markierte den String als vertrauenswürdig und reichte ihn unverändert durch.
Zwei unabhängige Funktionen. Ein vertrauenswürdiger Empfänger, installiert von einem Diagramm. Ein nicht vertrauenswürdiger Sender, geliefert von einer Vorschau. Eine Brücke über die Sandbox.
Von einer verirrten Nachricht zur vollständigen Kontoübernahme
Über innerHTML eingefügte Script-Tags laufen nicht von selbst, deshalb mussten die Forschenden noch die Zündschnur anzünden. Sie nutzten ein iframe mit srcdoc-Attribut, eingefügt ohne sandbox-Attribut. Das erzeugte ein frisches Dokument, in dem ein externes Script ausgeführt werden konnte, und weil die ChatGPT-Hauptseite den Frame erstellt hatte, gab der Browser ihm die Identität https://chatgpt.com. Code in diesem Frame konnte nun auf die übergeordnete Seite zugreifen.
Die Content Security Policy von ChatGPT blockierte Inline-JavaScript, wofür eine gute CSP genau da ist. Sie erlaubte jedoch Scripts von YouTube. Der oEmbed-Endpunkt von YouTube unterstützte einen JSONP-artigen Callback-Parameter und setzte diesen Callback freundlicherweise in seine Fehlerantwort, bevor er ihn validierte. Weil YouTube ohnehin auf der Erlaubnisliste stand, lud der Browser diese Antwort als Script und führte den Callback des Angreifers in dem neuen Frame aus.
Ergebnis: beliebiges JavaScript, ausgeführt als chatgpt.com, in einer angemeldeten Sitzung, erreichbar über einen Link.
Parameter machte die Zustellung dann langweilig, im besten Sinne für einen Angreifer. Sie packten das Diagramm und die Vorschau in eine ganz gewöhnliche öffentliche Unterhaltung, exportierten sie als normalen /share/<id>-Link und verschickten ihn so, wie jeder einen geteilten Chat verschickt: per E-Mail, in einer Chat-Nachricht, in einem Support-Ticket, als Social-Media-Beitrag. In der stabilsten Variante klickte das Opfer einmal auf Preview. In einer späteren Variante öffnete sich die Vorschau von selbst, und der Alarm kam nach etwa 4,5 Sekunden. Das Öffnen des Links war der einzige Klick.
Keine App-Installation. Kein Workspace-Beitritt. Kein Consent-Bildschirm. Keine Phishing-Seite, die fast echt aussieht.
Warum Ihr Unternehmen das trotz Patch betrifft
Es ist einfach, das unter "OpenAI-Bug, längst behoben, weitergehen" abzulegen. Diese Lesart übersieht die drei Dinge, die Ihre Organisation wirklich gefährden.
Erstens war die Angriffsfläche eine Funktion, zu deren Nutzung man ermutigt wird. Eine Unterhaltung zu teilen ist eine Kollaborationsfunktion, und Kollaborationsfunktionen werden meist per Default vertraut. Hier war es ein Link, der ausführbaren Code in eine authentifizierte Sitzung trug.
Zweitens war die Vertrauensgrenze die KI-Sitzung selbst. Als der Code lief, musste er keine Pixel vom Bildschirm ablesen. Er rief die eigenen authentifizierten APIs von ChatGPT als angemeldeter Nutzer auf. Jede Kontrolle, die beobachtet, worauf ein Mensch auf der Seite klickt, sieht nichts.
Drittens ist eine einzelne Sandbox-Flucht in einem Produkt selten ein isolierter Fehler. Diese Kette ist ein Rundgang durch ganz normale Entwicklungsabkürzungen: ein Message-Listener ohne Absenderprüfung, ein Sanitizer, der Eingaben als vertrauenswürdig markierte statt sie zu bereinigen, ein iframe ohne Sandbox und eine CSP-Erlaubnisliste, die weit genug ist, um einem Angreifer zu nützen. Diese Muster gibt es in jedem Projekt, das eine Integration schnell verdrahtet hat. Auch in unseren.
Der unangenehme Teil: die KI-Sitzung ist Ihr gesamter Kontext
Fragen Sie sich, was in den KI-Chats Ihres Teams steckt. Die Architektur eines Kunden. Eine Vertragsklausel im Umbau. Ein Migrationsplan. Zugangsdaten, einmal eingefügt und vergessen. Ein Preismodell, über das noch entschieden wurde.
Das ist kein Chat-Protokoll. Das ist die dichteste Konzentration von Geschäftskontext, die Sie besitzen, und sie hängt an einem einzelnen Session-Cookie, das meist nie abläuft.
Die Lektion ist nicht "KI ist gefährlich". Die Lektion ist, dass KI-Sitzungen dieselbe Behandlung verdienen wie eine Admin-Konsole und nicht wie ein Suchfeld.
Was wir diese Woche tun würden
- KI-Chat-Sitzungen wie privilegierte Identitäten behandeln. Re-Authentifizierung erzwingen, Sitzungslaufzeiten verkürzen und SSO mit Geräteprüfung verlangen, wo der Anbieter es unterstützt. Wenn das Session-Cookie das ganze Konto lesen kann, sollte es ablaufen wie eine Admin-Sitzung, nicht wie eine Lieblingswebseite.
- Automatische Vorschauen und ungeprüfte Links abschaffen. Auto-Preview für geteilte Inhalte deaktivieren, wo die Einstellung existiert, und dem Team sagen, dass ein unerwarteter Share-Link eine Nutzlast ist und keine Höflichkeit.
- Die API-Ebene protokollieren, nicht den Bildschirm. Wenn Ihr Monitoring nur Browseraktivität sieht, ist es für diese Angriffsklasse blind. Verfolgen Sie authentifizierte Aufrufe der APIs des KI-Produkts selbst, mit Alarmen zu Volumen und Umfang.
- Minimieren, was die Sitzung erreichen kann. Trennen Sie private und geschäftliche Konten. Halten Sie vertrauliche Kundeninhalte aus allgemeinen Chats heraus. Nutzen Sie Projekte oder Workspaces mit engerem Scope, wo es sie gibt, und löschen Sie, was Sie nicht mehr brauchen.
- Prüfen Sie Ihre eigenen Integrationen auf dieselben vier Fehler. Ungeprüfte
postMessage-Listener,innerHTML-Senken, iframes ohne Sandbox und CSP-Erlaubnislisten, die breiter sind als nötig. Das ist ein Zwei-Stunden-Review, das sich beim ersten Mal bezahlt macht. - Prüfen Sie Share-Funktionen von Anbietern, bevor Sie sie aktivieren. Fragen Sie, was ein geteiltes Artefakt in der Sitzung des Betrachters tun kann, nicht nur, was es zeigt.
Das Fazit
Die Branche hat gerade gesehen, wie ein öffentlich geteilter Link zu einem Auslieferungsweg für Code in eine authentifizierte KI-Sitzung wurde, und der Anbieter hat das in acht Tagen behoben, was wirklich schnell ist.
Was bleibt, ist die Designfrage, die jedes Team mit KI-Aufbau heute beantworten muss: Wie viel Kontext hält diese Sitzung, wie lange lebt sie, und was kann darin laufen?
Bei aratech bauen wir die KI-Infrastruktur, auf der unsere Kunden arbeiten, und genau das ist die Naht, zu der wir immer wieder zurückkommen. Agenten, Copiloten und Chat-Assistenten sind keine Anbauten an Ihrem Stack. Sie sind identitätstragende Komponenten mit Zugriff auf Ihren wertvollsten Kontext. Behandeln Sie die Sitzung als das Asset, das sie ist, und ein Link in einem Support-Ticket wird zur Lästigkeit statt zum Vorfall.
Wenn Sie ein zweites Paar Augen darauf wollen, wie weit Ihre KI-Sitzungen reichen, ist das genau das Gespräch, das wir gern führen.