Cloudflare-KI gab fremde Kundendaten aus: Was beim Modell GLM-5.3 schiefging und wer betroffen ist

IT-Sicherheit · KI-Dienste · Stand 27. Oktober 2026

Cloudflare-KI gab fremde Kundendaten aus: Was bei GLM-5.3 schiefging und wer betroffen ist

Zwei Wochen lang konnte ein KI-Modell auf Cloudflares Entwicklerplattform Workers AI Bruchstücke aus den Anfragen anderer Kunden in seine Antworten mischen. Cloudflare hat den Fehler im September behoben und erst am 26. Oktober öffentlich erklärt. Hier steht, was genau passiert ist, warum normale Website-Besucher nichts befürchten müssen und was Entwickler jetzt prüfen sollten.

• Betroffen: nur das Modell GLM-5.3 auf Workers AI, 27. August bis 9. September 2026
• 155 Antworten enthielten laut Cloudflare Daten anderer Kunden
• Ursache: zu kleiner KV-Cache plus Fehler in der Inferenz-Engine SGLang

Bin ich betroffen? Die Ursache erklärt

Cloudflare bestätigt, dass das KI-Modell GLM-5.3 auf seiner Plattform Workers AI in 155 Antworten Daten aus Anfragen anderer Kunden ausgegeben hat. Betroffen waren ausschließlich sehr lange Anfragen mit mehr als 681.280 Tokens im Zeitraum vom 27. August bis zum 9. September 2026. Die Ursache war kein Hackerangriff und kein „Gedächtnis“ der KI: Ein falsch dimensionierter Zwischenspeicher und ein Fehler in der Open-Source-Software SGLang führten dazu, dass die Inferenzserver nicht gelöschte Speicherreste früherer Anfragen weiterverwendeten. Das steht im ausführlichen Post-Mortem von Cloudflare vom 26. Oktober 2026.

Für die allermeisten Internetnutzer ist das trotz des großen Namens keine Gefahr: Wer eine Website besucht, die über Cloudflare ausgeliefert oder geschützt wird, war von diesem Vorfall nicht betroffen. Relevant ist er für Entwickler und Unternehmen, die GLM-5.3 über Workers AI genutzt haben – und für alle, die KI-Schnittstellen mit sensiblen Daten füttern. Dieser Beitrag erklärt die Technik verständlich, zeigt die Zeitleiste mit deutscher Uhrzeit, trennt Cloudflares Angaben von denen des Entdeckers und ordnet die offenen Datenschutzfragen ein.

Stand: 27. Oktober 2026, 16:00 Uhr. Grundlage sind das Post-Mortem von Cloudflare, der parallel veröffentlichte Sicherheitsbeitrag des SGLang-Teams, die Cloudflare-Statusseite sowie der Bericht des Entdeckers Knostic. Wie viele Kunden betroffen sind, ob sie benachrichtigt wurden und ob Behörden informiert wurden, hat Cloudflare nicht veröffentlicht. Wir aktualisieren den Beitrag bei neuen Angaben.

Cloudflare-KI-Datenpanne: Das Wichtigste in 20 Sekunden

Was ist bei Cloudflare passiert?

Ein auf Cloudflare gehostetes KI-Modell hat Kunden Antworten geliefert, in denen Teile fremder Anfragen steckten. Konkret ging es um GLM-5.3, ein großes Sprachmodell des chinesischen Anbieters Z.ai (Zhipu AI), das Cloudflare seinen Entwicklerkunden seit Ende August 2026 über die Plattform Workers AI anbietet. Wer dem Modell eine extrem lange Anfrage schickte, bekam in bestimmten Fällen keine Fehlermeldung, sondern eine scheinbar normale Antwort. Diese beruhte aber teilweise auf Prompts und halb fertigen Antworten anderer Kunden, die kurz zuvor dasselbe Modell genutzt hatten.

Cloudflare zählt 155 solcher Antworten. Laut Unternehmen gab es keine Hinweise darauf, dass jemand den Fehler gezielt ausgenutzt hat: Die betroffenen Anfragen hätten in Zeitpunkt und Menge zu normaler Nutzung mit langen Kontexten gepasst, ausgenommen die Testanfragen des Forschers und eigene Tests. Wörtlich heißt es im Post-Mortem „We found no evidence of deliberate exploitation“ – sinngemäß: Man habe keine Belege für eine absichtliche Ausnutzung gefunden. Eine unabhängige Bestätigung dieser Analyse gibt es nicht.

Bemerkenswert ist vor allem der zeitliche Abstand. Behoben war der Fehler am 9. September. Auf der öffentlichen Statusseite stand an diesem Tag nur, dass es beim Modell GLM 5.3 vermehrt zu Fehlern komme. Dass dahinter ein Sicherheitsvorfall mit Daten anderer Kunden steckte, wurde erst am 26. Oktober in einer koordinierten Veröffentlichung von Cloudflare und dem SGLang-Team bekannt – rund 47 Tage später.

Welcher Dienst betroffen war: Workers AI und GLM-5.3

Betroffen war nicht „Cloudflare“ im Ganzen, sondern ein einzelnes Modell auf einem einzelnen Entwicklerdienst. Workers AI ist Cloudflares Plattform, auf der Entwickler KI-Modelle auf Cloudflare-Grafikkarten ausführen lassen – aufgerufen aus eigenen Programmen, aus Cloudflare Workers oder über eine Programmierschnittstelle. Endnutzer sehen diesen Dienst nicht direkt; sie nutzen höchstens Apps und Werkzeuge, die im Hintergrund darauf zugreifen.

GLM-5.3 hat Z.ai am 14. August 2026 veröffentlicht. Cloudflare nahm das Modell laut Post-Mortem am 27. August in Betrieb, der zugehörige Changelog-Eintrag ist auf den 28. August datiert – vermutlich der Unterschied zwischen technischer Inbetriebnahme und Ankündigung. Beworben wurde GLM-5.3 mit einem Kontextfenster von rund einer Million Tokens, also der Menge Text, die das Modell auf einmal verarbeiten kann. Typischer Einsatz sind sogenannte agentische Coding-Workflows, bei denen ganze Codebasen, Dokumente oder Protokolle in eine Anfrage gepackt werden.

Wichtig für die Einordnung: Das Modell von Z.ai trifft keine Schuld. Cloudflare betont, dass alle anderen Modelle mit getrenntem Prefill- und Decode-Betrieb einen ausreichend großen Zwischenspeicher hatten. Der Fehler entstand in Cloudflares eigener Konfiguration und in der von Cloudflare eingesetzten Open-Source-Software.

Die Ursache verständlich erklärt: KV-Cache, Prefill und Decode

Zwei Fehler kamen zusammen: ein zu kleiner Zwischenspeicher und eine Software, die eine zu große Anfrage nicht sauber ablehnte. Um das zu verstehen, hilft ein kurzer Blick darauf, wie große Sprachmodelle eine Anfrage verarbeiten. Beim sogenannten Prefill liest das Modell zunächst den gesamten Prompt ein und berechnet dabei für jedes Token Zwischenergebnisse. Diese landen im KV-Cache (Key-Value-Cache), damit das Modell beim anschließenden Schreiben der Antwort – dem Decode – nicht alles neu berechnen muss.

Cloudflare betreibt Prefill und Decode auf getrennten Grafikkarten. Der Prefill-Knoten rechnet den Prompt durch und schickt den KV-Cache in Speicherseiten per schneller Netzwerkverbindung (RDMA) an den Decode-Knoten, der dann die Antwort erzeugt. Dieses Verfahren heißt disaggregiertes Serving und gilt als effizient, weil sich beide Arbeitsschritte unabhängig skalieren lassen.

Technisch beschreibt Cloudflare den Kern so: Die Ablehnung wurde in einem internen Feld vermerkt, das die Engine nicht als „Anfrage beendet“ auswertete. Der Prefill-Knoten verarbeitete deshalb nur den Platzhalter, übertrug eine einzige Speicherseite und meldete den Transfer als abgeschlossen. Der Decode-Knoten hatte im Beispiel des Post-Mortems acht Seiten reserviert, beschrieben war nur die erste. Über die anderen sieben rechnete das Modell trotzdem – und die enthielten noch Inhalte früherer Anfragen. Im Post-Mortem steht dazu der entscheidende Satz „Pages are not currently zeroed between requests“, auf Deutsch sinngemäß: Speicherseiten werden zwischen Anfragen derzeit nicht genullt, die nächste Anfrage überschreibt sie einfach.

Eine Analogie: Stell dir einen Copyshop vor, der für jeden Auftrag einen Stapel Blätter reserviert. Normalerweise wird jedes Blatt neu bedruckt. In diesem Fall wurde nur das erste Blatt bedruckt, der Rest des Stapels stammte noch vom vorherigen Kunden – und wurde ungeprüft mitgeliefert. Das Ergebnis sah aus wie ein ordentlicher Auftrag, enthielt aber fremde Seiten. Genau so bekam der Kunde von Workers AI den HTTP-Status 200 („alles in Ordnung“) statt einer Fehlermeldung mit Status 400.

Der Sicherheitsbeitrag des SGLang-Teams beschreibt zusätzlich eine verwandte Wettlaufsituation (Race Condition): Bricht ein Kunde eine Anfrage ab, während der KV-Cache noch übertragen wird, und gibt der Decode-Knoten den Speicher zu früh frei, können verspätet eintreffende Daten den Zwischenspeicher einer anderen Anfrage verfälschen. Laut SGLang geschah das jeweils unbemerkt. Betroffen sind demnach Standardkonfigurationen mit getrenntem Prefill und Decode über RDMA seit der v0.4-Reihe Anfang 2025 bis Version 0.5.21. Wer SGLang nur als Einzelinstanz ohne Datenübertragung zwischen Engines betreibt, ist von dieser Race Condition nicht betroffen. Eine CVE-Kennung nennt der Beitrag nicht.

Vorgeschichte, die nachdenklich macht: Der gleiche Fehler im Annahmepfad war bereits am 6. Juli 2026 von einem anderen Nutzer als SGLang-Issue #30233 gemeldet worden – mit der Beschreibung, dass abgebrochene zu lange Prefill-Anfragen im Decode „Unsinn“ aus unvollständigem KV-Cache erzeugen. Und Cloudflare hatte bereits im August eine Integritätsprüfung für Speicherseiten getestet, sie Mitte August aber wegen Zuverlässigkeitsproblemen wieder abgeschaltet. Beim Start von GLM-5.3 war sie deshalb nicht aktiv.

Warum nur Anfragen über 681.280 Tokens betroffen waren

Cloudflare erlaubte Anfragen bis 1.048.576 Tokens, der Zwischenspeicher der Prefill-Grafikkarten fasste aber nur 681.280. Alles dazwischen landete im fehlerhaften Ablehnungspfad. Laut Post-Mortem kannte Cloudflare diese Lücke vor dem Start. Die Tests mit langen Kontexten prüften jedoch nur HTTP-Statuscodes und die Leistung der Engine, nicht ob die Antworten inhaltlich zum Prompt passten. Cloudflare räumt das selbst ein.

Tokens laut Cloudflare-Post-Mortem; Balken relativ zum größten Wert.

KV-Pool bis 9.9. 681.280

Erlaubter Kontext 1.048.576

KV-Pool seit 9.9. ca. 2,04 Mio.

Quelle: Cloudflare, Post-Mortem vom 26.10.2026. Anfragen zwischen 681.280 und 1.048.576 Tokens konnten den Fehler auslösen; längere Anfragen wurden korrekt mit HTTP 400 abgelehnt.

Zur Größenordnung: Eine Million Tokens entspricht grob mehreren Hunderttausend Wörtern oder einer mittelgroßen Codebasis. Solche Anfragen schickt kaum jemand von Hand. Sie entstehen vor allem, wenn KI-Agenten ganze Projektverzeichnisse, lange Gesprächsverläufe oder Dokumentensammlungen in eine Anfrage packen. Genau diese Anfragen enthalten aber oft vertrauliche Inhalte – Quellcode, Kundendaten, interne Dokumente. Einordnung: Die hohe Schwelle hat die Zahl der Fälle begrenzt, die Brisanz der möglicherweise betroffenen Inhalte aber eher erhöht.

Welche Daten betroffen waren – und was offen bleibt

Cloudflare beschreibt die offengelegten Inhalte nur allgemein als Prompts und Teilantworten anderer Nutzer. Ob darin personenbezogene Daten steckten, sagt das Unternehmen nicht. Auch eine Zahl der betroffenen Kunden fehlt; die Rede ist lediglich von „a small number of customers“, also einer kleinen Zahl von Kunden. Unklar bleibt zudem, ob damit die Empfänger der fehlerhaften Antworten gemeint sind oder auch die Kunden, deren Daten in fremden Antworten auftauchten.

Konkreter wird der Entdecker. Laut dem Bericht von Knostic tauchten in den beobachteten Antworten unter anderem Personennamen, Kunden- und Firmennamen, Rechnungsnummern, Eurobeträge, Zahlungstermine, Hinweise auf Quellcode sowie Datei- und Verzeichnispfade auf. Knostic veröffentlicht keine Klardaten, sondern nur Zählungen. In einem Fall habe man ein öffentliches Code-Repository gefunden, dessen Pfade und Feldnamen zu einer geleakten Ausgabe passten – ausdrücklich als Korrelation, nicht als Beweis. Wichtig: Das sind Angaben des Forschers, Cloudflare bestätigt diese Datenarten nicht.

Wie Cloudflare die 155 Antworten im Nachhinein identifiziert hat, beschreibt das Post-Mortem nicht. Laut der Datenschutzseite von Workers AI speichert der Dienst Ein- und Ausgaben bei normaler Nutzung nicht über die Verarbeitung hinaus und trainiert nicht damit – es sei denn, Kunden aktivieren Logging oder Caching im vorgeschalteten AI Gateway. Für betroffene Kunden heißt das: Die eigenen Protokolle sind oft die einzige Grundlage, um nachzuvollziehen, was sie im fraglichen Zeitraum erhalten oder gesendet haben.

Zeitleiste: Vom Start bis zum Post-Mortem (UTC und MESZ)

Zwischen Meldung und Abschaltung des Modells vergingen knapp 15 Stunden, zwischen Korrektur und Offenlegung rund sieben Wochen. Die folgenden Zeiten stammen aus dem Post-Mortem und von der Statusseite; Cloudflare gibt sie in UTC an. Im September galt in Deutschland die Sommerzeit (MESZ = UTC + 2 Stunden).

1. 06.07.2026Bug in SGLang gemeldetEin Nutzer beschreibt den Fehler als GitHub-Issue #30233; Cloudflare wird erst später darauf aufmerksam.
2. Mitte August 2026Schutz abgeschaltetCloudflare deaktiviert einen Prototyp zur Integritätsprüfung von Speicherseiten wegen Zuverlässigkeitsproblemen.
3. 14.08.2026GLM-5.3 erscheintZ.ai veröffentlicht das Modell.
4. 27.08.2026Start auf Workers AIGLM-5.3 geht mit zu kleinem KV-Pool in Betrieb – ab hier ist der Fehler auslösbar.
5. 07.09.2026Spur führt zu CloudflareLaut Knostic wird die zuvor über OpenRouter bemerkte Auffälligkeit Cloudflare zugeordnet.
6. 9.9., 01:11 MESZMeldung über HackerOne8.9., 23:11 UTC. Prüfung beginnt am Morgen um 10:00 MESZ (08:00 UTC).
7. 9.9., 15:22 MESZVorfall ausgerufen13:22 UTC. Das Leck ist binnen 25 Minuten mit zwei unabhängigen Konten reproduziert.
8. 9.9., 16:00 MESZModell gesperrt14:00 UTC. Um 16:25 MESZ meldet die Statusseite „erhöhte Fehler“ – nicht aber einen Sicherheitsvorfall.
9. 9.9., 16:52 MESZKonfiguration korrigiert14:52 UTC. Alle Prefill-Knoten laufen mit vergrößertem Speicher.
10. 9.9., 21:40 MESZWieder verfügbar19:40 UTC. Statusseite um 22:09 MESZ auf „gelöst“.
11. 11.–19.09.2026HärtungCloudflare sichert alle produktiven SGLang-Installationen zusätzlich ab.
12. 24.09.2026Ticket geschlossenLaut Knostic wird die HackerOne-Meldung als gelöst geschlossen.
13. 02.10. / 19.10.2026SGLang-UpdatesVersionen 0.5.21 und 0.5.22 enthalten die Korrekturen.
14. 26.10.2026Öffentliche ErklärungCloudflare und SGLang veröffentlichen ihre Berichte koordiniert, Knostic folgt am 27. Oktober.

Die Statusseite vom 9. September sprach von „increased Workers AI errors“, also vermehrten Fehlern beim Aufruf von GLM 5.3. Technisch war das korrekt, denn das Modell lieferte während der Sperre tatsächlich Fehlermeldungen. Den Sicherheitsaspekt erfuhren Außenstehende dort aber nicht. Einordnung: Koordinierte Offenlegung nach Abschluss aller Korrekturen ist in der Sicherheitsbranche üblich, damit andere Betreiber derselben Software Zeit zum Patchen haben. Für die betroffenen Kunden selbst ist aber entscheidend, ob und wann Cloudflare sie direkt informiert hat – und dazu schweigt der Bericht.

Wie der Sicherheitsforscher den Fehler fand

Entdeckt hat den Fehler Gadi Evron vom Sicherheitsunternehmen Knostic – laut eigener Darstellung bei ganz normaler Arbeit. Über den KI-Vermittler OpenRouter seien in Antworten plötzlich fremde Dateipfade und chinesischsprachige Anleitungen aufgetaucht, die nichts mit der eigenen Anfrage zu tun hatten. Am 7. September habe man Cloudflare als zuständigen Anbieter identifiziert und anschließend direkt mit einem eigenen Cloudflare-Konto getestet.

Die Methode ist auch für Entwickler lehrreich: Knostic setzte eindeutige Markierungen an Anfang und Ende großer Fülltexte und prüfte, ob die Antwort diese Markierungen kennt. Bis etwa 662.000 Tokens war alles korrekt, ab rund 700.000 Tokens traten die Fehler auf, bei etwa 745.000 Tokens ließen sie sich zuverlässig reproduzieren. Anfragen über 1.048.576 Tokens lehnte der Dienst sauber ab. Andere Modelle wie GLM-5.2 oder GLM-5.3 Flash zeigten das Verhalten laut Knostic nicht. Knostic gibt außerdem an, Workers AI habe zeitweise ein noch größeres Kontextfenster von 1.310.720 Tokens beworben; das steht nicht im Post-Mortem.

Offen bleibt die Rolle von OpenRouter. Wenn die erste Beobachtung dort stattfand, könnten auch Nutzer von Aggregatoren betroffen gewesen sein, die Anfragen an Cloudflare als Anbieter weiterreichen. Ob Cloudflare tatsächlich als Anbieter für GLM-5.3 bei OpenRouter gelistet war, ließ sich nicht unabhängig überprüfen. Auch die Höhe der Bug-Bounty nennen weder Cloudflare noch Knostic.

Bin ich betroffen? Der Schnell-Check

Für Privatnutzer lautet die Antwort fast immer: nein. Relevant ist der Vorfall nur für Entwickler und Firmen, die GLM-5.3 über Workers AI mit sehr langen Anfragen genutzt haben, und indirekt für Nutzer von Apps, die das taten. Wähle deine Situation – die Einschätzungen sind unsere Einordnung auf Basis von Cloudflares Angaben.

Wichtig ist die doppelte Perspektive: Ein Kunde kann Empfänger fremder Daten gewesen sein, wenn er selbst sehr lange Anfragen gestellt hat. Er kann aber auch Quelle gewesen sein, wenn Reste seiner Anfragen im Speicher lagen und einem anderen Kunden geliefert wurden. Für die zweite Gruppe gilt die Token-Schwelle nicht. Wie viele Kunden in diese Kategorie fallen, hat Cloudflare nicht offengelegt.

Kein zweites Cloudbleed: Warum Website-Besucher sicher sind

Der Vorfall ist strukturell anders und deutlich enger begrenzt als das berüchtigte Cloudbleed von 2017. Damals hatte ein Fehler im HTML-Parser des Cloudflare-Proxys Speicherinhalte direkt in ausgelieferte Webseiten geschrieben – darunter Cookies, Authentifizierungstoken und Formulardaten fremder Websites. Laut dem damaligen Vorfallsbericht von Cloudflare war etwa eine von 3,3 Millionen Anfragen betroffen, und Teile davon landeten in Suchmaschinen-Caches.

Beim GLM-5.3-Fehler lag das Problem dagegen in den Grafikkarten-Servern eines einzelnen KI-Modells. Der Weg, über den Cloudflare Millionen Websites ausliefert und schützt, war nicht beteiligt. Einordnung: Die Gemeinsamkeit beider Fälle ist dieselbe Fehlerklasse – wiederverwendeter Speicher, der Daten eines Kunden einem anderen zugänglich macht. Die Reichweite ist aber nicht vergleichbar.

Was Cloudflare seitdem geändert hat

Cloudflare hat den Speicher vergrößert, die Software gepatcht und neue Pflichtprüfungen eingeführt. Laut Post-Mortem fasst der KV-Pool auf den Prefill-Knoten jetzt rund 2,04 Millionen Tokens, etwa das Doppelte des Kontextfensters. Ein Prompt, der ins Kontextfenster passt, passt damit immer auch in den Speicher, sodass der fehlerhafte Ablehnungspfad bei gültigen Anfragen gar nicht mehr erreicht wird.

Für alle, die SGLang selbst im getrennten Prefill/Decode-Betrieb einsetzen, empfehlen Cloudflare und das SGLang-Team: mindestens Version 0.5.22 verwenden, die KV-Speichergröße gegen das Kontextfenster auf jedem Knoten messen, die verzögerte Speicherfreigabe auf beiden Rollen aktivieren und Prüfsummen sowie Kontrollmarker einschalten. Ein Satz aus dem Post-Mortem fasst die Lehre zusammen, sinngemäß übersetzt: Verlasse dich nicht darauf, dass ein Proxy das Limit durchsetzt, und nimm nicht an, dass die Engine ablehnt, was nicht passt. Die Leistungskosten der Korrekturen sind laut SGLang statistisch nicht messbar.

Was im Post-Mortem fehlt: eine Entschuldigung und konkrete Handlungsempfehlungen an Workers-AI-Kunden. Der Bericht ist detailliert und technisch offen, richtet sich aber vor allem an Betreiber von Inferenz-Infrastruktur.

DSGVO und Meldepflichten: Wer muss jetzt was tun?

Cloudflare äußert sich im Post-Mortem weder zu Behördenmeldungen noch zur Benachrichtigung von Kunden. Das ist rechtlich relevant, weil in langen Prompts häufig personenbezogene Daten stecken. Die folgende Einordnung ist eine allgemeine Ableitung aus Vertrag und Gesetz, keine Rechtsberatung im Einzelfall.

Nach dem Auftragsverarbeitungsvertrag von Cloudflare handelt das Unternehmen bei Kundendaten als Auftragsverarbeiter und verpflichtet sich, Kunden „without undue delay“ – also unverzüglich – über Sicherheitsverletzungen zu informieren. Eine feste Stundenfrist nennt der Vertrag nicht. Die Pflicht zur Meldung an die Aufsichtsbehörde trifft nach Art. 33 DSGVO den Verantwortlichen, also den Workers-AI-Kunden: möglichst binnen 72 Stunden, nachdem er von der Verletzung erfahren hat, es sei denn, sie führt voraussichtlich nicht zu einem Risiko für die betroffenen Personen. Bei voraussichtlich hohem Risiko kommt nach Art. 34 DSGVO die Benachrichtigung der Betroffenen hinzu.

Unsere Einschätzung: Die 72-Stunden-Frist beginnt erst, wenn der Kunde Kenntnis hat. Ob und wann Cloudflare die Kunden informiert hat, deren Daten in fremden Antworten auftauchten, ist der zentrale offene Punkt. Ob eine Aufsichtsbehörde eingebunden wurde – für Cloudflare in der EU wäre das voraussichtlich die irische Datenschutzbehörde als federführende Stelle –, ist ebenfalls nicht bekannt. Unternehmen, die GLM-5.3 im Zeitraum genutzt haben, sollten nicht auf eine Nachricht warten, sondern aktiv nachfragen und das Ergebnis dokumentieren.

Offene Fragen an Cloudflare

Das Post-Mortem erklärt die Technik ausführlich, lässt aber genau die Fragen offen, die für Betroffene am wichtigsten sind. Auch deutschsprachige Fachberichte wie bei BornCity oder s-edv.com stützen sich auf dieselben Quellen und können diese Lücken nicht füllen. Große Tech-Medien hatten bis zum Nachmittag des 27. Oktober noch nicht berichtet.

Ähnliche Fälle: Wenn KI-Dienste fremde Daten zeigen

Der Cloudflare-Fall reiht sich in eine Serie von Vorfällen ein, bei denen geteilte Infrastruktur Daten zwischen Kunden durchlässt. Am bekanntesten ist der ChatGPT-Ausfall vom 20. März 2023: Ein Fehler in der Bibliothek redis-py führte laut OpenAIs Bericht dazu, dass Nutzer fremde Chat-Titel sahen und bei 1,2 Prozent der im Zeitfenster aktiven Plus-Abonnenten Name, E-Mail, Zahlungsadresse sowie die letzten vier Ziffern und das Ablaufdatum der Kreditkarte sichtbar werden konnten.

Einordnung: Das gemeinsame Muster ist wiederverwendeter Speicher ohne Löschung – KV-Seiten, Datenträgerblöcke, GPU-Speicher – sowie abgebrochene oder abgelehnte Anfragen, die einen inkonsistenten Zustand hinterlassen. Auffällig ist, dass Cloudflare im September 2026 kurz hintereinander zwei solcher Fälle in verschiedenen Produkten hatte. Wer sich für die Sicherheitsseite der KI-Branche interessiert, findet bei uns auch den Hintergrund zu OpenAIs abgeschottetem KI-Training und zum Fall, in dem eine OpenAI-KI Hugging Face angriff.

Auch klassische Software-Lücken bleiben ein Dauerthema: Aktuell beschäftigen Admins die Node2Shell-Lücke in der Brotli-Bibliothek und die vom BSI gemeldeten PHP2Shell-Schwachstellen. Einen Überblick über größere Vorfälle des Jahres bietet unser Beitrag zu Cyberangriffen 2026.

Checkliste für Entwickler und Unternehmen

Diese Punkte helfen, den eigenen Status zu klären und künftige Risiken bei KI-Schnittstellen zu senken. Die ersten fünf betreffen Workers-AI-Kunden, die übrigen gelten für jede Nutzung externer KI-Dienste. Die Liste speichert deinen Fortschritt in diesem Browser.

Ein Punkt verdient besondere Beachtung: Kontextfenster nicht ausreizen, nur weil es möglich ist. Wer statt eines ganzen Repositorys nur die relevanten Dateien schickt, spart Kosten und senkt das Risiko, dass vertrauliche Inhalte überhaupt in fremde Hände geraten können. Eigene Instanzen oder dedizierte Deployments verringern das Risiko einer Vermischung mit anderen Kunden – verlagern aber die Verantwortung für eine korrekte Konfiguration auf den Betreiber selbst, wie dieser Fall eindrücklich zeigt.

Mehr aktuelle Themen vom 27. Oktober 2026

Häufige Fragen zur Cloudflare-KI-Datenpanne

TransparenzQuellen und Datenbasis22 Einträge

Grundlage sind das Post-Mortem von Cloudflare und der Sicherheitsbeitrag des SGLang-Teams vom 26. Oktober 2026, ergänzt um Cloudflare-Dokumentation, den Bericht des Entdeckers und Rechtstexte. Alle Quellen am 27. Oktober 2026 abgerufen. Bereits im Text verlinkte Quellen führen wir ohne erneuten Link auf, Beiträge von drohnen.de nicht erneut.

• Cloudflare-Blog: „Cross-request KV cache exposure in the GLM-5.3 Workers AI model, and our remediation with SGLang“ (26.10.2026) – im Text verlinkt; Hauptquelle (Unternehmensquelle)
• SGLang/LMSYS: „SGLang security update: improving request isolation“ (26.10.2026) – im Text verlinkt (Unternehmensquelle)
• Cloudflare Status: Vorfall Workers AI/GLM 5.3 (9.9.2026) – im Text verlinkt (Unternehmensquelle)
• Cloudflare Changelog: GLM-5.3 auf Workers AI (28.8.2026) – im Text verlinkt (Unternehmensquelle)
• Cloudflare: Modellseite GLM-5.3 – Kontextfenster, Preise, Modellanbieter (Unternehmensquelle)
• Cloudflare: Datenschutz bei Workers AI – im Text verlinkt (Unternehmensquelle)
• Cloudflare Customer DPA – im Text verlinkt; Auftragsverarbeitung, Benachrichtigungspflicht (Unternehmensquelle)
• Cloudflare-Blog: „Smaller, faster, safer“ (3.8.2026) – Integritätsprüfung von Speicherseiten (Unternehmensquelle)
• Cloudflare-Blog: Containers-Vorfall (24.9.2026) (Unternehmensquelle)
• Cloudflare-Blog: Cloudbleed-Vorfallsbericht (23.2.2017) – im Text verlinkt (Unternehmensquelle)
• GitHub: SGLang-Issue #30233 (6.7.2026) – im Text verlinkt
• OpenAI: „March 20 ChatGPT outage“ (24.3.2023) – im Text verlinkt (Unternehmensquelle)
• Art. 33 DSGVO – im Text verlinkt (Rechtstext)
• Art. 34 DSGVO (Rechtstext)
• Knostic (Gadi Evron): Bericht zum Cross-Tenant-Leck (27.10.2026) – im Text verlinkt (Forscherangaben)
• NDSS 2025: „I Know What You Asked“ (PROMPTPEEK) (Fachpublikation)
• Trail of Bits: LeftoverLocals (16.1.2024) (Fachquelle)
• BornCity (27.10.2026) (Fachmedium)
• s-edv.com (27.10.2026) (Fachmedium)
• DataStudios (27.10.2026) (Fachmedium)
• InfoQ: Cloudflare Containers (5.10.2026) (Fachmedium)
• datanorth.ai: Release GLM-5.3 (Fachmedium)