„Das Öffnen des geteilten Links war die einzige Handlung, die das Opfer ausführen musste“, so beschreibt das Sicherheitsforschungsteam einen Angriff, den es im Oktober 2026 dokumentiert hat. Wer einen geteilten Link öffnet, rechnet nicht damit, dass fremder Code im eigenen, angemeldeten Konto läuft. Laut Bericht war genau das möglich.
Die Forschenden beschreiben, wie ein Angreifer eine gewöhnliche Unterhaltung erstellt, sie über die normale Teilen-Funktion veröffentlicht und den Link an andere schickt. Beim Öffnen lief der Code im Kontext von chatgpt.com, also mit Zugriff auf die angemeldete Sitzung des Besuchers. Von dort ließen sich Unterhaltungen auflisten, Inhalte aus einem nie geteilten privaten Chat abrufen und nach außen senden. OpenAI hat das Problem am 26. Oktober behoben und als P1 eingestuft.
Zwei Funktionen, die allein harmlos sind
Der Ausgangspunkt war eine schlichte Frage: Wenn Vorschau-Code in einer anderen Website eingesperrt ist, mit wem kann er dann noch sprechen? ChatGPT kann einen HTML-Codeblock über die Preview-Funktion in eine kleine, funktionierende Webseite verwandeln. Weil dort beliebiger Code stecken kann, läuft diese Seite in einem eingeschränkten Frame unter einer anderen Webadresse. Der Browser behandelt sie damit wie eine fremde Website, die nicht einfach in die umgebende ChatGPT-Seite hineinschauen kann.
Zunächst funktionierte diese Isolation wie vorgesehen. Code in der Vorschau konnte nicht auf parent.document zugreifen, also nicht auf das eigentliche ChatGPT-Dokument. Damit hätte die Sache enden können. In derselben Unterhaltung steckte aber ein normaler interaktiver Graph, und der lud im Hintergrund eine Mathematik-Bibliothek namens MathLive.
Dieses Laden zeichnete nicht nur einen Graphen. Es installierte zugleich einen Zuhörer in der Hauptseite, der auf Nachrichten für die Bildschirmtastatur von MathLive reagierte. Der Browser stellt dafür die Schnittstelle postMessage bereit, einen legitimen Weg, wie zwei Frames Informationen austauschen können, obwohl sie sich gegenseitig nicht lesen dürfen. Man kann sich das als Briefschlitz vorstellen: Der eingesperrte Frame kann nicht durch die Wand gehen, aber er kann etwas durch den Schlitz schieben. Sicher ist das nur, wenn der Empfänger prüft, wer da eingeworfen hat.
MathLive machte diese Prüfung für die fragliche Einstellung nicht. Der Zuhörer akzeptierte eine Nachricht, die das Layout der virtuellen Tastatur änderte, und dieses Layout durfte HTML enthalten. Damit war der Empfänger im Hauptdokument vorhanden, und die Vorschau lieferte den ungeprüften Absender gleich mit. Zwei unabhängige Funktionen hatten gemeinsam einen Pfad quer durch die Sandbox gebaut.
MathLive nahm postMessage ohne Absenderprüfung an
Die Vorschau verschickte zwei Nachrichten. Die erste ersetzte ein Tastatur-Layout durch eigenes HTML, die zweite wies MathLive an, die Tastatur anzuzeigen, woraufhin die Bibliothek das neue Layout rendern sollte. Der öffentliche Nachrichtentyp wurde erkannt, aber der übergeordnete Controller arbeitete mit einer Origin-Richtlinie von none, akzeptierte also Nachrichten von jeder beliebigen Webadresse. Zusätzlich verlangte er nicht, dass die update-setting-Nachricht aus einem zuvor freigegebenen Fenster stammte.
Wer den Zuhörer erreichen und das Format kennen konnte, durfte das Layout austauschen. Beim Öffnen der Tastatur fügte MathLive das gelieferte Layout zu einem HTML-String zusammen und wies ihn dem innerHTML der echten ChatGPT-Seite zu. Eine Hilfsfunktion namens createHTML sah zunächst nach einer Bereinigung aus, tat aber das Gegenteil: Sie markierte die Zeichenkette als vertrauenswürdig und reichte das HTML unverändert weiter. Damit war fremdes Markup in der Hauptseite, noch ohne JavaScript-Ausführung.
Von eingeschleustem HTML zu echtem JavaScript
Script-Tags, die über innerHTML eingefügt werden, laufen im Browser nicht automatisch. Dieser Umweg hätte den Angriff fast gestoppt. Der nächste Schritt war deshalb ein iframe mit srcdoc, einem Attribut, das den HTML-Inhalt eines eingebetteten Frames direkt mitliefert. MathLive fügte diesen Frame ohne sandbox-Attribut in das ChatGPT-Dokument ein, und das hatte zwei nützliche Folgen für den Angreifer.
Erstens entstand ein frisches Dokument, in dem ein externes Skript ausgeführt werden konnte. Zweitens erbte der Frame die Web-Identität https://chatgpt.com, weil die Hauptseite ihn erzeugt hatte, sodass Code darin auf die übergeordnete Seite zugreifen durfte. Die Isolation der ursprünglichen Vorschau war damit nicht aufgehoben, sondern umgangen: Eine vertrauenswürdige Komponente im Hauptdokument hatte einen ungeprüften Dokumentenrahmen gebaut.
Dann griff die Content Security Policy ein, kurz CSP, die vorschreibt, welche Skripte eine Seite laden darf. Inline-JavaScript war blockiert. Erlaubt waren jedoch Skripte von YouTube, und der oEmbed-Endpunkt von YouTube unterstützte einen JSONP-artigen Callback-Parameter. JSONP liefert kein reines JSON, sondern JavaScript; die Schnittstelle versuchte einen ungültigen Callback abzulehnen, setzte ihn aber vor der Fehlermeldung in die Antwort.
Ein Callback, der mit ;void endete, machte das von YouTube angehängte Objekt harmlos, während der eigene Code stehen blieb. Da YouTube in der CSP bereits erlaubt war, lud der Browser die Antwort als Skript und führte den Callback in dem neuen Frame aus. Damit lief beliebiger JavaScript-Code mit der Identität von chatgpt.com.
Ein öffentlicher Share-Link genügte
Der erste funktionierende Aufbau war noch kein realistischer Alltagsangriff: Er nutzte eine vom Forscherteam kontrollierte ChatGPT-App als Absender. Ein Opfer hätte diese App erst verbinden oder aufrufen müssen, was die Hürde unrealistisch hoch machte. Ein weiterer Versuch mit einem nativen HTML-Anhang scheiterte an der Veröffentlichung: Der Anhang blieb im geteilten Chat erhalten, der Graph verschwand jedoch beim Export.
Ohne den Graphen fehlte der Empfänger, denn niemand hatte MathLive geladen und den verwundbaren Zuhörer installiert. Die Lösung bestand darin, beide Teile in eine gewöhnliche Unterhaltung zu legen: einen echten Graphen, der MathLive in der Hauptseite initialisiert, und eine später vom Assistenten erzeugte HTML-Vorschau, die die beiden Nachrichten sendet. Der resultierende /share/-Link enthielt die vollständige Kette.
Ausgeliefert werden konnte er wie jede andere geteilte Unterhaltung, per E-Mail, Chat, Support-Ticket oder Social-Media-Beitrag. Das Opfer musste nichts installieren, keinem Workspace beitreten und sich durch keinen angreiferkontrollierten Anmeldeablauf klicken. In der stabilsten Variante war ein Klick auf die normale Vorschau-Schaltfläche nötig, später genügte das bloße Öffnen des Links, weil der HTML-Block als vorschaufähig markiert wurde. Das Team reproduzierte diesen automatischen Pfad dreimal in einem separaten Konto, der Alarm erschien nach etwa 4,5 Sekunden.
Weil Graph und Vorschau unabhängig laden, konnte die Nachricht gelegentlich eintreffen, bevor MathLive bereit war. Der finale Träger wiederholte die beiden Nachrichten deshalb für einen begrenzten Zeitraum, während eine Sperre in der Hauptseite sicherstellte, dass der Nachweis nur einmal ausgeführt wurde.
Was der Angreifer im Konto konnte – und was OpenAI behob
Der Code konnte mehr als einen Alarmdialog anzeigen. Weil das JavaScript als chatgpt.com lief, durfte es mit derselben authentifizierten Umgebung arbeiten wie die normale Webanwendung. Die Nutzlast las die bereits in der Seite vorhandenen Sitzungsinformationen und rief damit die Konversations-APIs von ChatGPT auf.
Zuerst ließen sich die letzten Unterhaltungen des Opfers auflisten, danach gezielt Nachrichtendaten einer ausgewählten privaten Konversation anfordern. Das war direkter authentifizierter API-Zugriff, kein Abgreifen von sichtbarem Bildschirmtext. Die Zielunterhaltung hatte nichts mit dem bösartigen Share zu tun und war nie mit dem Angreifer geteilt worden. Für den Abtransport genügte anschließend eine gewöhnliche Bildanfrage an einen kontrollierten Server.
Bewusst wurde nur ein kleiner Ausschnitt übertragen, obwohl der eingeschleuste Code die gesamte Antwort bereits gelesen hatte. Die Reichweite war nicht auf die getesteten Endpunkte beschränkt. Alles, was die authentifizierte Frontend-API der Webanwendung hergibt, lag innerhalb derselben Sicherheitsgrenze. Der Code konnte damit im Namen des Opferkontos handeln.
OpenAI reproduzierte sowohl die JavaScript-Ausführung als auch den Nachweis mit der privaten Unterhaltung. Der Fix wurde über zwei Versionen des Web-Frontends ausgerollt; zwischenzeitlich blockierten CSP-Änderungen einen Teil der Kette, während eine Version noch ein Update brauchte. Am 26. Oktober bestätigte OpenAI, dass beide Versionen die besagten MathLive-Nachrichten über Frame-Grenzen hinweg ablehnen, und stufte den Bericht als P1 ein.
Drei Designentscheidungen machten aus einzelnen Fehlern einen ausnutzbaren Ablauf: MathLive akzeptierte eine zustandsändernde Nachricht ohne Nachweis des Absenders, das Nachrichtenformat erlaubte rohes HTML als Tastatur-Layout, und dieses HTML konnte ein nicht sandboxed Dokument erzeugen, das die chatgpt.com-Identität erbte. Die YouTube-Antwort war nur der letzte Ausweg um die CSP herum, nicht die Ursache. Wer ausschließlich diesen Endpunkt blockiert hätte, hätte einen Weg zu JavaScript geschlossen und die HTML-Einfügung in ChatGPT stehen lassen.
Was das für den Alltag mit KI-Assistenten bedeutet
Die Lehren für Verteidiger sind einfach. Ein Nachrichtenempfänger sollte sowohl die Webadresse des Absenders als auch das konkret freigegebene Fenster prüfen. Einstellungen, die zwischen Fenstern wandern, sollten kein rohes HTML enthalten. Dynamisch erzeugte Dokumente sollten sandboxed bleiben, wenn ihr Inhalt von einem nicht vertrauenswürdigen Frame beeinflusst werden kann. Und eine CSP ist eine Rückfallebene, nicht der einzige Schutz, nachdem fremdes HTML die Hauptseite erreicht hat.
Für Nutzerinnen und Nutzer heißt das nicht, dass sie in Panik geraten müssen: Die Lücke ist geschlossen, und ein Browser oder eine Web-App lässt sich aktualisieren. Geteilte Links bleiben fremde Inhalte, auch wenn sie auf einer vertrauten Domain liegen. Wer Unterhaltungen von Unbekannten öffnet, sollte das bewusst tun. Der Angriff brauchte kein Installieren, kein Passwort, keine Erweiterung, nur einen Klick auf etwas, das aussah wie eine normale Freigabe.
Für Entwickler zeigt der Fall, wie wichtig das Zusammenspiel ist. Jede einzelne Funktion war vernünftig: Die Vorschau war isoliert, Graphen durften eine Mathetastatur laden, Frames durften Nachrichten austauschen, die CSP erlaubte einen großen Medienanbieter, öffentliche Unterhaltungen ließen sich teilen. Die Verwundbarkeit entstand erst, als all das auf einer Seite zusammentraf. Deshalb reicht es nicht, einzelne Komponenten zu prüfen. Man muss auch testen, wie sie zusammenwirken.
Quelle: parameter.ai
