Check Point Research hat eine kontoübergreifende Isolationslücke in der Codeausführungsumgebung von ChatGPT dokumentiert, durch die eine gewöhnliche Unterhaltung zu einem verborgenen Aufgabenkanal werden konnte. Im kontrollierten Nachweis der Forschenden rief eine Sitzung Daten aus einem verbundenen Gmail-Konto ab und übermittelte sie an ein anderes ChatGPT-Konto, während die sichtbare Antwort normal wirkte.
Die Erkenntnisse wurden am 8. September 2026 veröffentlicht. Entscheidend ist der genaue Angriffsweg: Das Modell brauchte weder direkten Internetzugriff noch gestohlene Kontodaten oder einen klassischen Ausbruch aus dem Container. Getrennte Codecontainer konnten denselben internen Paketdienst erreichen. Veränderbare Metadaten dieses Dienstes waren nicht nach Konten getrennt und konnten deshalb Anweisungen und Ergebnisse zwischen Sitzungen übertragen.
Der betroffene Pfad ist nicht mehr verfügbar. Check Point erklärt, der Kanal sei bereits verschwunden gewesen, als der Bericht abgeschlossen wurde. OpenAI bestätigte laut den Forschenden, dass die identifizierte interne Artifactory-Instanz außer Betrieb genommen worden war. Die Veröffentlichung belegt weder eine breite Ausnutzung noch betroffene Kunden. Sie beschreibt kontrollierte Forschung aus dem Juni und einen konkreten Funktionsnachweis.
So funktionierte der verborgene Kanal
Für Aufgaben mit Codeausführung erstellte ChatGPT isolierte Container. Laut Check Point konnten diese Container weder direkt miteinander kommunizieren noch auf das öffentliche Internet zugreifen. Sie durften jedoch einen gemeinsamen internen JFrog-Artifactory-Dienst verwenden, um Softwarepakete abzurufen.
Der Paketabruf selbst war nicht das Problem. Der Dienst stellte Funktionen bereit, mit denen ein Container Eigenschaften an ein Repository-Objekt anhängen und diese Eigenschaften später lesen konnte. Die im Container verfügbaren Zugangsdaten reichten für beide Vorgänge aus. Check Point schrieb einen Testwert aus einem Konto und las genau diesen Wert aus einem anderen Konto. Größere Datenmengen ließen sich auf mehrere Eigenschaften verteilen und wieder zusammensetzen.
Dadurch entstand eine Art gemeinsame Zwischenablage. Ein Angreifer konnte eine versteckte Anweisung in den Kanal legen. Ein schädlicher Prompt, eine geteilte Unterhaltung oder ein speziell konfigurierter GPT konnte die Sitzung des Opfers anweisen, bei einem späteren Schritt nach dieser Nachricht zu suchen. Die sichtbare Anfrage erhielt weiterhin eine gewöhnliche Antwort, während eine zweite Aufgabe mit den Werkzeugen und Rechten der Opfersitzung ausgeführt wurde.
Die Gmail-Demonstration zeigt, warum ein Lesezugriff erhebliche Folgen haben kann. Check Point zufolge erschien beim Opfer ein kleiner Hinweis auf die Gmail-Nutzung. Er wurde aber erst nach dem Zugriff angezeigt und erklärte weder die verborgene Anfrage noch die zurückgegebenen Daten. Der Nachweis verband damit drei Grenzen, die häufig getrennt geprüft werden: Mandantentrennung, Vertrauen in Anweisungen und Autorisierung verbundener Anwendungen.
Was die Belege zeigen und was nicht
Die technischen Primärbelege stammen vom Sicherheitsforscher und nicht aus einem öffentlichen Vorfallbericht von OpenAI. Unabhängige Berichte von TechRadar und The Register bestätigen den beschriebenen Mechanismus, die Gmail-Demonstration und die Schließung des identifizierten Kanals. Für die technischen Einzelheiten stützen sie sich jedoch auf Check Point.
Die Forschung zeigt, dass der Pfad in der getesteten Umgebung funktionierte. Sie zeigt nicht, dass ein Angreifer ihn gegen Kunden eingesetzt hat. Ebenso belegt sie nicht, dass jede ChatGPT-Funktion, jeder Kontotyp oder jede verbundene Anwendung betroffen war. Die mögliche Wirkung hing von den Werkzeugen, Daten und Berechtigungen der jeweiligen Sitzung ab.
Diese Abgrenzung ist für die Reaktion auf Vorfälle wichtig. Teams sollten nicht jeden früheren Gmail-Lesezugriff oder jede geteilte Unterhaltung als Kompromittierung behandeln. Sie sollten den Bericht nutzen, um eigene Agentenplattformen auf gemeinsamen internen Zustand, zu weit reichende Laufzeitrechte und Leseaktionen ohne angemessene Autorisierung zu prüfen.
Die Kontrolllehre reicht über einen Dienst hinaus
Containerisolation ist nur eine Schicht eines Sicherheitsmodells für Agenten. Jede interne API, jeder Cache, Paketproxy, Metadatenspeicher und jede Verwaltungsoberfläche, die von der Laufzeit erreichbar ist, gehört in das Bedrohungsmodell. Kann ein Mandant Zustand verändern, den ein anderer lesen kann, entsteht ein verdeckter Kanal, obwohl die Netzisolation wie vorgesehen funktioniert.
Verbundene Anwendungen vergrößern die mögliche Folge. Eine Laufzeit, die E-Mails, Quellcode, Dateien oder Kollaborationsdaten lesen kann, sollte nur die für die aktuelle Aufgabe erforderlichen Rechte erhalten. Sensible Lesezugriffe müssen nach Datentyp, Anfragendem, Zweck und Ziel bewertet werden. Sie sind nicht automatisch risikoarm, nur weil sie keinen externen Datensatz verändern.
Auch die Herkunft einer Anweisung ist wichtig. Text aus einer geteilten Unterhaltung, einer Agentenkonfiguration, einem abgerufenen Dokument oder einer externen Nachricht darf nicht automatisch dieselbe Autorität wie die aktuelle Nutzeranfrage erhalten. Die Plattform muss vertrauenswürdige Aufgabenanweisungen von nicht vertrauenswürdigen Inhalten trennen und verhindern, dass verborgener Text den Umfang unbemerkt erweitert.
Teams können diese Grenzen mit der Maetra Secure Sandbox testen. Der Leitfaden zu KI-Auditprotokollen hilft, Prompts, Werkzeugaufrufe, Datenzugriffe und Ergebnisse zu verbinden, ohne unnötige Inhalte zu sammeln.
Fragen für eine Unternehmensprüfung
Sicherheits- und Plattformteams sollten alle gemeinsamen Dienste erfassen, die eine Agentenlaufzeit erreichen kann. Für jeden Dienst ist zu klären, welche Werte über Sitzungen hinweg geschrieben oder gelesen werden können. Laufzeitzugangsdaten sollten auf Rechte geprüft werden, die über den Paketabruf hinausgehen, insbesondere Metadaten- und Verwaltungsfunktionen.
Auch Lesezugriffe verbundener Anwendungen verdienen eine eigene Prüfung. Sieht der Nutzer vorab, welche Ressource gelesen wird? Ist die Autorisierung an die aktuelle Aufgabe und Identität gebunden? Kann eine geerbte oder versteckte Anweisung den Zugriff auslösen? Speichern Protokolle die Herkunft der Anweisung, den Werkzeugaufruf, die Datenkategorie und das Ziel?
Schließlich sollte der vollständige Fehlerpfad getestet werden. Eine Sitzung muss isoliert oder widerrufen, Zugangsdaten müssen rotiert und unerwartete sitzungsübergreifende Kennungen müssen auffindbar sein. Eine Untersuchung sollte einen blockierten Versuch von einem abgeschlossenen Datenzugriff unterscheiden können.
Maetra-Analyse
Die zentrale Governance-Lehre lautet, dass Autorisierung dem vollständigen Aktionspfad folgen muss. Eine Netzsandbox kann korrekt funktionieren, während gemeinsamer Zustand einen anderen Weg um die angenommene Trennung öffnet. Ein Werkzeugrecht kann für den Nutzer gültig sein, obwohl die auslösende Anweisung aus einer nicht autorisierten Quelle stammt.
Die praktische Kontrolleinheit ist daher nicht nur der Container oder Connector. Sie umfasst Mandant, Sitzung, Anweisungsquelle, Werkzeug, Ressource, Zweck und Ziel. Wird dieser Rahmen protokolliert und durchgesetzt, werden verborgene Aufgaben schwerer und Ermittler erhalten brauchbare Nachweise, wenn eine Grenze versagt.
Der Bericht ist ein guter Grund, gemeinsame Infrastruktur und Rechte verbundener Anwendungen erneut zu testen. Er ist kein Beleg dafür, dass der geschlossene Kanal weiterhin ausnutzbar ist oder Kundenkonten breit kompromittiert wurden.