Ein lokal erzeugter Chatverlauf eines nicht-OpenAI-Providers wird nachträglich in eine Memory-Sitzung geladen und an einen OpenAI-Endpunkt übertragen. Das passiert nicht im Rahmen von Analytics oder Telemetrie, sondern als gewöhnlicher Modell-Inferenz-Request.
Dieser Vorgang ist als Codex Memory Exfiltration bekannt geworden. Der Sicherheitsforscher, der den Vorfall untersuchte, hat die Übertragung mit der offiziellen Windows-Binärdatei 0.150.0-alpha.12.2 in einer kontrollierten Umgebung nachvollzogen. Für dich heißt das: Wer Codex mit Memories nutzt, muss damit rechnen, dass Inhalte aus lokalen Provider-Sitzungen an OpenAI fließen – auch wenn alle Telemetrie- und Analyse-Features deaktiviert sind. Es ist ein Datenabfluss, der sich unterhalb des üblichen Datenschutz-Radars bewegt.
Der kontrollierte Beweis: Ein lokaler Chat landet bei OpenAI
Der Forscher nutzte eine isolierte Codex-Installation mit aktivierten Memories, aber deaktiviertem Analytics und allen OpenTelemetry-Exporten auf none. Als Quelle diente ein synthetischer Rollout mit eindeutigen Markern – sogenannten Canaries –, der mit dem Provider-Label synthetic_source gespeichert war. Nachdem ein OpenAI-gestützter Codex-Prozess die Memory-Erzeugung anstieß, sendete die Software eine 38.095 Byte große WebSocket-Nachricht an den Endpunkt chatgpt.com/backend-api/codex/responses.
Die Nachricht trug die Kennung request_kind = memory und bestand aus drei Top-Level-Elementen: einem Developer-Item für zusätzliche Tools, einer Memory-Instruktion und einer User-Nachricht, die den serialisierten Quell-Chat enthielt. In diesem User-Wrapper fanden sich 3.092 Byte des ursprünglichen Verlaufs. Die fünf übertragenen Quell-Elemente stimmten strukturell exakt mit dem gespeicherten Rollout überein: die Umgebungsdaten, die normale User-Nachricht, ein Tool-Call samt Argumenten, die Tool-Ausgabe mit Fehlertext und Pfaden sowie eine synthetische Assistant-Antwort.
OpenAI quittierte den Vorgang mit response.created und response.completed. Das antwortende Modell gpt-5.6-luna erzeugte eine 3.405 Zeichen lange Memory-Notiz, die die eindeutigen Canaries mehrfach reproduzierte. Damit war nicht nur ein Verbindungsversuch belegt, sondern eine echte Verarbeitung der übertragenen Inhalte. Die Antwort zeigt: Der Datenabfluss ist ein faktischer, kein bloß theoretischer Vorgang.
Warum die Provider-Grenze fällt: Drei Schritte im Quellcode
Der gemeldete Vorfall ist keine Panne einer einzelnen Version. Der Forscher verweist auf den getaggten Quellcode von Codex, der drei Stationen des Memory-Prozesses dokumentiert. In der ersten Stufe wählt der Memory-Job einen geeigneten früheren Rollout aus. Dabei prüft er Kriterien wie Memory-Modus, Alter, Idle-Zustand, Quelltyp und Claim-Status – aber nicht den Provider, unter dem der Rollout entstanden ist. Der entsprechende Aufruf übergibt für model_providers den Wert None.
In der zweiten Stufe erzeugt der Worker den Provider aus der aktuell aktiven Sitzung. Die Memory-Runtime liest config.model_provider und nutzt diesen Client für den späteren Request. In der dritten Stufe lädt Phase 1 den ausgewählten Rollout, filtert die zu behaltenden Elemente, packt sie in eine neue User-Nachricht und sendet sie über den Memory-Client. So entsteht die Kette: Ein lokaler Provider-Rollout wird durch eine spätere OpenAI-Sitzung ausgewählt und über deren Provider versendet.
Das ist die eigentliche ChatGPT Codex Sicherheitslücke. Die Auswahl der Quelle und der Ziel-Provider sind entkoppelt. Es gibt keine Bedingung, die einen unter einem lokalen Provider erzeugten Chat vor einer Übertragung an OpenAI schützt. Die einzige Hürde sind andere Ausschlusskriterien, die den spezifischen Rollout möglicherweise nicht für die Memory-Erzeugung freigeben. Genau darin steckt das providerübergreifende Datenleck: Die Erinnerung kennt keine Herkunftsbindung.
Welche Inhalte betroffen sind: Vom Chat bis zum Tool-Fehler
Die Filterlogik, die vor dem Senden angewendet wird, ist kein Geheimnis, aber sie ist überraschend weit gefasst. Übertragen werden können vollständige User- und Assistant-Nachrichten, Agent-Nachrichten, lokale Shell-Aufrufe, Funktionsaufrufe samt Ausgaben, Tool-Suchen, Web-Suchen, benutzerdefinierte Tool-Ausgaben und konvertierte Inter-Agent-Kommunikation. Ausgeschlossen sind Entwickler-Nachrichten, Reasoning-Aufzeichnungen, Kompaktierungen, einige generierte Medien oder Tool-Deklarationen und Buchhaltungsdatensätze.
Bei längeren Verläufen wird der Inhalt mittig gekürzt: auf 70 Prozent des effektiven Modellkontexts, mit einer Ausweichgrenze von 150.000 Token. Anfang und Ende bleiben erhalten. Für einen normalen kurzen Thread bedeutet das: Praktisch die gesamte Konversation, inklusive Tool-Aktivität, Umgebungspfaden und Fehlermeldungen, kann als Quellmaterial verwendet werden. Es geht also nicht um einzelne Zeilen, sondern um umfangreiche Verlaufsbestandteile.
Die vor dem Versand angewendete Schwärzung ist kein Datenschutz-Werkzeug. Der Filter erkennt klassische Muster wie sk- Schlüssel, AWS-Kennungen, lange Bearer-Tokens und Werte mit Namen wie api_key, token oder password. In einem Test entfernte er genau solche Muster. Er ließ jedoch untypische Schlüssel, cookie-ähnliche Werte, E-Mail-Adressen, Telefonnummern, private Header, vertrauliche Prosa, Windows-Pfade und die eigentlichen Inhalt-Canaries unangetastet. Wer hofft, dass eine Redaktion vor dem Transfer vertrauliche Details entfernt, wird enttäuscht.
Analytics aus, Telemetrie aus: Warum der Kanal trotzdem offen ist
Eine wichtige Eigenschaft dieses Vorfalls: Die Einstellungen, die man normalerweise für Datenschutz zuständig macht, greifen hier nicht. In der Testumgebung waren [analytics] enabled = false gesetzt und alle OpenTelemetry-Exporter auf none. Der Request wanderte trotzdem an OpenAI. Die Ursache ist die getrennte Verwaltung der Systeme. Analytics und Telemetrie sind separate Pfade; die Memory-Erzeugung ist ein eigener, funktional notwendiger Modell-Inferenz-Request.
Der einzige aktuelle Schalter, der diesen Kanal zuverlässig unterbricht, ist das Deaktivieren der Memories selbst: [features] memories = false. Es gibt keine Option, die Memories aktiv lässt und zugleich die Provider-Übergrenzung verbietet. Der Forscher betont, dass Nutzer nicht darauf kommen müssen, dass das Abschalten von Analytics und Telemetrie einen separaten Hintergrund-Request übrig lässt, der fremde Provider-Inhalte überträgt. Das ist eine Dokumentations- und Designschwäche – und aus Nutzersicht eine versteckte Datenübertragung. Wer das nicht riskieren will, muss die Memory-Funktion komplett abschalten.
So lässt sich der Vorfall kontrolliert nachstellen
Für die Reproduktion ist kein echter privater Chat nötig. Der Forscher beschreibt eine minimale Testumgebung: eine isolierte Codex-Home mit aktivierten Memories, deaktiviertem Analytics und deaktivierten OpenTelemetry-Exporten. Dazu kommt ein berechtigter früherer Rollout, dessen Provider-Label nicht OpenAI ist und dessen Nachrichten eindeutige synthetische Canaries enthalten. Dieser Rollout muss die Memory-Bedingungen erfüllen. Danach triggert eine OpenAI-gestützte Codex-Sitzung die Memory-Verarbeitung.
Ein lokaler TLS-Inspektionsproxy fängt den ausgehenden WebSocket-Request ab. Entscheidend sind die Felder request_kind = memory und die eingebetteten Elemente des Quell-Rollouts. Bestätigt wird der Vorgang, wenn die Server-Antwort die einzigartigen Canaries reproduziert. Der Forscher hat genau das getan und damit die Übertragung eindeutig belegt. Diese Vorgehensweise zeigt zugleich, wie sich der Abfluss sicher und ohne echte Nutzerdaten demonstrieren lässt.
Erwartetes Verhalten wäre aus seiner Sicht: Ein Rollout aus einem lokalen oder Drittanbieter-Provider darf nicht ohne ausdrückliche, zielbezogene Zustimmung an einen anderen Provider gesendet werden. Die Memory-Erzeugung sollte entweder den Provider der Quelle verwenden oder den Rollout überspringen, wenn dieser Provider nicht verfügbar ist. Falls die Funktion gewollt ist, müsste sie als Opt-in ausgeführt werden und vor dem Senden das Ziel sowie die betroffenen Inhaltsklassen nennen. Außerdem fordert er eine Quittung in der Benutzeroberfläche, die zeigt, welche Aufgabe verarbeitet wurde, welcher Anbieter sie empfangen hat und wann das geschah.
Einordnung: Daten, die niemals hätten fließen dürfen
Der Bericht endet mit einer klaren Bewertung: Es handele sich um Datenexfiltration im üblichen Sinne – private Daten wurden ohne informierte Autorisierung aus der gewählten Provider-Grenze an einen entfernten Empfänger übertragen. Ob das Ergebnis eines Bugs oder einer bewussten Entscheidung ist, ändere nichts an der Grenzüberschreitung. Der Forscher verbindet den Vorfall zudem mit einer OpenAI-Kontowarnung wegen „Cyber Abuse“, die in keinem Zusammenhang mit den an OpenAI gerichteten Chats gestanden habe. Die entsprechenden Inhalte seien nur in einem bewusst an einen lokalen Provider gerichteten Verlauf vorhanden gewesen.
Daraus leitet er ab, dass OpenAI möglicherweise Konten auf Basis von Inhalten bewertet hat, die es rechtlich nicht hätte erhalten dürfen. Er zieht einen drastischen Vergleich: Das sei, als öffne jemand ohne Erlaubnis die Schlafzimmertür, missbillige das Gesehene und bestrafe die Person dafür. Die Metapher ist bewusst überspitzt, macht aber pointiert klar, worum es geht: eine nicht autorisierte Informationsübertragung mit potenziellen Folgen für das Nutzerkonto.
Solange keine offizielle Antwort vorliegt, bleibt die Lage angespannt. Der Forscher fordert OpenAI auf, alle zugehörigen Dokumente, Logs und Moderationsaktionen aufzubewahren, den Umfang der Übertragung offenzulegen, betroffene Nutzer zu informieren und negative Kontoentscheidungen zu überprüfen. Ein stilles Reparieren der Provider-Auswahl wäre unzureichend. Für Nutzer von Codex mit Memories bedeutet das: Es ist an der Zeit, die eigene Konfiguration zu überdenken, bis die Hersteller klare Antworten liefern. Bis dahin ist das Abschalten der Memory-Funktion die einzige wirksame Kontrolle – und ein deutlicher Hinweis, dass die Trennung der Provider-Grenzen noch nicht zu den selbstverständlichen Sicherheitsmerkmalen gehört.
Quelle: github.com
