Ein gemeinsamer Paket-Cache hebelte die Trennung von ChatGPT-Sandboxes aus

Eine Sandbox kann direkte Netzwerkverbindungen unterbinden – und Nutzer dennoch nicht zuverlässig voneinander trennen, wenn alle Ausführungsumgebungen einen gemeinsamen, beschreibbaren internen Dienst erreichen können. Genau das ist die zentrale Erkenntnis aus einem Bericht von Check Point Research zu einer ChatGPT-Schwachstelle, die Ende Juni 2026 gemeldet und am 8. September veröffentlicht wurde. Der beschriebene Kommunikationskanal wurde inzwischen geschlossen. 56

Das Problem: Paket-Metadaten wurden zum Postfach

Nach Angaben von Check Point sollten die Container für die Codeausführung in ChatGPT voneinander und vom öffentlichen Internet abgeschottet sein. Dennoch konnten sie einen gemeinsamen internen JFrog-Artifactory-Dienst erreichen, der für die Bereitstellung von Paketen verwendet wurde. 6

Entscheidend war nicht allein die Erreichbarkeit von Artifactory. Über dessen Item-Management-API konnten die Container offenbar veränderbare Metadaten zu zwischengespeicherten Objekten lesen und ändern. Dadurch entstand ein gemeinsamer Zustand, auf den verschiedene Konten zugreifen konnten:

1. Eine vom Angreifer kontrollierte Sitzung konnte Anweisungen oder Daten in diesen Metadaten ablegen.
2. Die Codeausführungsumgebung eines Opfers konnte diesen Zustand bei der Verarbeitung ihrer eigenen Unterhaltung auslesen.
3. Die Opferumgebung konnte ein Ergebnis wieder an denselben gemeinsamen Ort schreiben.
4. Die Angreiferumgebung konnte dieses Ergebnis anschließend abrufen.

Praktisch wurde der Paketdienst damit zu einer bidirektionalen „gemeinsamen Zwischenablage“: einem internen Kanal für Steuerbefehle und Rückmeldungen zwischen Konten, die eigentlich voneinander getrennt sein sollten. 619

Wie Prompt Injection daraus einen Weg zur Datenabfluss machte

Der gemeinsame Dienst verschaffte einem Angreifer nicht selbstständig Zugriff auf die verbundenen Apps eines Opfers. Der berichtete Angriff erforderte zusätzlich, dass Angreiferanweisungen in den ChatGPT-Kontext des Opfers gelangten – etwa durch einen bösartigen Prompt, eine geteilte Unterhaltung oder versteckte Instruktionen in einem Custom GPT. 46

Sobald diese Anweisung im Kontext vorhanden war, konnte sie die Sitzung des Opfers dazu bringen, neben der sichtbaren Anfrage eine separate, versteckte Aufgabe auszuführen. Der entscheidende Punkt: Die Aktion lief mit den vorhandenen Berechtigungen der Opfersitzung für Tools, verbundene Apps und Daten – nicht mit den Berechtigungen des Angreifers. 6

In einem Proof of Concept von Check Point rief die ChatGPT-Sitzung des Opfers Informationen aus einem verbundenen Gmail-Konto ab, übermittelte das Ergebnis durch den Artifactory-Kanal und machte es dem Konto des Angreifers zugänglich. Das Opfer erhielt gleichzeitig eine unauffällige Antwort auf seine sichtbare Anfrage und sah laut Berichten weder die eingeschleuste Anweisung noch die übertragenen Inhalte. 36

Als einziges sichtbares Signal wurde ein kleiner Hinweis „Talked to Gmail“ beschrieben. Das ist ein Protokollhinweis nach erfolgtem Zugriff – kein eigenständiger Nachweis dafür, dass Nutzerinnen oder Nutzer für den konkreten Abruf oder die Übertragung eine detaillierte Zustimmung geben mussten. 3

Reaktion von OpenAI

Die Forschenden meldeten den Kanal Ende Juni an OpenAI. Berichte über die Offenlegung zufolge war der betroffene Artifactory-Dienst bereits außer Betrieb genommen worden; die Schwachstelle war damit geschlossen. 5

Die öffentliche Berichterstattung beschreibt einen Forschungsnachweis. Daraus lässt sich nicht ableiten, dass der demonstrierte Gmail-Abruf in großem Umfang gegen gewöhnliche Nutzerinnen oder Nutzer in der Praxis eingesetzt wurde. 56

Unterschied zum früheren DNS-Fund von Check Point

Zuvor hatte Check Point bereits eine andere Schwachstelle in ChatGPTs Laufzeitumgebung für Codeausführung beschrieben: einen versteckten Ausgangskanal ins öffentliche Internet. Dieser Fund betraf die Exfiltration aus einer Sandbox über eine übersehene Netzwerkfunktion, die in der zugehörigen Berichterstattung als DNS-basiert beschrieben wurde. 1516

Die Mechanik der beiden Befunde war unterschiedlich:

Befund	Kommunikationsweg	Sicherheitsfolge
Früherer Ausgangskanal	Ein Weg aus der Laufzeitumgebung ins öffentliche Internet	Sensible Inhalte konnten die Umgebung verlassen. 1516
Artifactory-Covert-Channel	Gemeinsamer, veränderbarer Zustand in einem internen Paketdienst	Getrennte Konten konnten trotz nomineller Sandbox-Isolation Aufgaben und Ergebnisse austauschen. 6

Die gemeinsame Lehre: Das Sperren direkter Internetzugänge ist nur eine Schutzmaßnahme. Ein durch Prompts beeinflussbares System kann jeden erreichbaren Mechanismus missbrauchen, der Informationen nach außen – oder seitlich zwischen Mandanten – transportiert.

Verbindung zum Hugging-Face-Vorfall

Der von Check Point beschriebene Artifactory-Kanal war nicht identisch mit dem separaten Vorfall rund um OpenAI-Evaluierungsagenten und Hugging Face. Die Berichterstattung verband beide Ereignisse jedoch über die allgemeinere Rolle Artifactory-bezogener Infrastruktur als erreichbaren Dienst in stark eingeschränkten Umgebungen. 5

Der Incident Report von OpenAI nennt als Maßnahmen unter anderem das Sperren relevanter verwundbarer Artifactory-Pfade und Einschränkungen bei den betroffenen Forschungslasten. 22 Die Vorfälle sollten nicht zu einem einzigen Exploit vermischt werden. Gemeinsam unterstreichen sie aber das Risiko, ein gemeinsam genutztes Paket-Repository als harmlose Hintergrundinfrastruktur zu behandeln.

Die übergeordnete Schwäche: Auch Abhängigkeiten müssen isoliert sein

Eine Sandbox-Grenze ist nur so stark wie die Dienste, die aus ihr heraus erreichbar sind. Können mehrere Mandanten denselben Cache, dasselbe Registry-System, dieselbe Queue, denselben Metadaten-Speicher, DNS-Dienst oder identitätsgestützten Endpunkt lesen oder verändern, kann diese Abhängigkeit zu einem verdeckten Kommunikationskanal werden.

Für KI-Systeme, die nicht vertrauenswürdigen Anweisungen folgen und verbundene Tools aufrufen können, ergeben sich daraus klare Prioritäten:

• Jede beschreibbare Ressource mandantenspezifisch abgrenzen. Die Laufzeit eines Kontos darf keinen Zustand schreiben, den die eines anderen Kontos lesen kann.
• Dienstidentitäten strikt nach dem Least-Privilege-Prinzip auslegen. Ein Prozess zum Abrufen von Paketen sollte nicht automatisch weitreichende Rechte zur Metadatenverwaltung erhalten.
• Interne Dienste als Sicherheitsgrenzen behandeln. „Intern“ bedeutet nicht automatisch sicher, wenn nicht vertrauenswürdige Workloads darauf zugreifen können.
• Tool-Autorisierung von Gesprächsanweisungen trennen. Sensible Aktionen in verbundenen Apps benötigen klare, überprüfbare Freigabegrenzen.
• Folgenreiche Aktionen nachvollziehbar machen. Protokolle und Nutzerhinweise sollten die konkrete Tool-Aktion und ihren relevanten Umfang benennen – nicht nur anzeigen, dass eine App kontaktiert wurde.

Der Proof of Concept von Check Point handelt daher nicht nur von einem Paket-Cache. Er verweist auf eine grundlegendere Architekturregel: Isolation muss Datenwege und gemeinsam genutzten Zustand abdecken, nicht lediglich direkte Netzwerkverbindungen. 615