Die Kurzfassung
Eine Speichereinstellung in Cloudflare Containers verzichtete darauf, wiederverwendete Datenblöcke zu nullen – ein neuer Container konnte so Fragmente lesen, die der gelöschte Container eines anderen Kunden hinterlassen hatte. Cloudflare hat das binnen Tagen behoben, keine Hinweise auf Missbrauch gefunden und verlangt keine Maßnahmen von Kunden. Wer Workloads auf Cloudflare Workers und der zugehörigen Container-Runtime betreibt, nimmt vor allem eines mit: Ein gelöschter Datenträger ist nicht automatisch leer.
Behandeln Sie jeden geteilten Cloud-Datenträger nach der Freigabe als nicht vertrauenswürdig – und legen Sie Secrets gar nicht erst darauf ab.
Was hat Cloudflare offengelegt?
Am 24. September 2026 veröffentlichte Cloudflare ein Post-Mortem zu einer mandantenübergreifenden Datenexposition in Containers, der Container-Runtime neben Workers, sowie in Sandboxes, in denen nicht vertrauenswürdiger Code wie Aufgaben von KI-Agenten läuft. Demnach hätte ein Workers-Paid-Kunde Restdaten aus Speicherblöcken wiederherstellen können, die zuvor Container anderer Kunden auf demselben Host belegt hatten.
Der Sicherheitsforscher Oren Yomtov von Accomplish meldete das Problem am 4. September um 15:26 UTC über Cloudflares HackerOne-Programm. Cloudflare bestätigte es rund drei Stunden später in der Produktion und mergte noch am selben Abend einen Runtime-Fix. BleepingComputer und The Hacker News berichteten in den Tagen darauf.
Laut Cloudflare enthielten die wiederhergestellten Blöcke Verzeichnisstrukturen, Datenbankseiten und strukturell vollständige SQLite-Datenbanken. Der Bericht der Forscher nennt laut beiden Medien außerdem Chromium-Browserprofile, .env-Dateien und Dateien mit Zugangsdaten. Nach eigener Aussage lieferten ihre Skripte nur aggregierte Zählwerte, keine Dateiinhalte.
Wie gelangten Daten zwischen Mandanten?
Die Container-Datenträger wurden per Thin Provisioning über den Linux Device Mapper aus einem gemeinsamen Pool geschnitten. Für den Pool war die Option skip_block_zeroing aktiv – der Kernel nullt einen neu zugewiesenen Block also nicht, bevor er ihn herausgibt. Die Blöcke waren 64 KiB groß. Schrieb ein neuer Container nur wenige Kilobyte in einen frisch zugewiesenen Block, stand im Rest noch, was der Vorbesitzer hineingeschrieben hatte.
Auf das Nullen zu verzichten ist ein verbreiteter Performance-Kompromiss, denn jeder gelöschte Block kostet I/O. Gehört der Pool einem einzigen Mandanten, ist das unkritisch; teilen ihn viele, wird es gefährlich. Cloudflare hat die Option entfernt, alle vor der Gegenmaßnahme angelegten Container-Datenträger ausgemustert, gecachte Image-Snapshots gelöscht und Hosts außerhalb der Spitzenzeiten geleert und neu gestartet.
Zwei Grenzen machten das Risiko kleiner, als es klingt: Ein Angreifer konnte sich kein Opfer aussuchen und keinen Datenträger lesen, der noch an einem laufenden Container hing. Abfließen konnte nur, was zufällig auf freigegebenem Speicher zurückgeblieben war.
Was bedeutet das für Softwareteams?
Erstens: „Gelöscht“ heißt auf geteilter Infrastruktur nicht „vernichtet“. Es ist dieselbe Fehlerklasse wie Restdaten in wiederverwendeten Cloud-Volumes oder im GPU-Speicher, und sie wird bei anderen Anbietern wieder auftauchen. Ihr Bedrohungsmodell für jede Multi-Tenant-Plattform, auch für neuere Cloudflare-Produkte, sollte davon ausgehen, dass freigegebener Speicher für Dritte lesbar sein kann.
Zweitens: Sandboxes für KI-Agenten erhöhen den Einsatz. Teams lassen zunehmend agentengenerierten Code, Browsersitzungen und temporäre Datenbanken in kurzlebigen Containern laufen. Genau dort entstehen die Daten, die dieser Fehler offenlegte: Browserprofile, lokale SQLite-Dateien und .env-Dateien mit API-Schlüsseln. Kurzlebig heißt nicht risikoarm, wenn der Datenträger den Container überdauert.
Drittens: Compliance hängt weiter an Ihren eigenen Kontrollen. Weil Cloudflare keinen Missbrauch gefunden hat, ist das für die meisten Kunden kein meldepflichtiger Vorfall. Unter DSGVO, HIPAA oder SOC 2 müssen Sie aber zeigen können, dass personenbezogene Daten und Zugangsdaten auch dann geschützt sind, wenn die Isolation des Anbieters versagt. Verschlüsselung auf Anwendungsebene und kurzlebige Credentials machen genau diese Aussage möglich.
Was bedeutet das für den DACH-Markt?
Im DACH-Raum wird Cloud-Einkauf stark über Nachweise gesteuert: Viele Unternehmen und öffentliche Auftraggeber fragen nach einem Testat gemäß BSI C5, dem Cloud-Kriterienkatalog des Bundesamts für Sicherheit in der Informationstechnik, und prüfen Mandantentrennung sowie sicheres Löschen im Rahmen der Auftragsverarbeitung. Der Cloudflare-Fall zeigt, warum ein Zertifikat beim Onboarding nicht reicht: Die Schwachstelle steckte in einer Performance-Einstellung, nicht in einem fehlenden Prozess.
Für die Praxis heißt das: Nehmen Sie „Restdaten auf freigegebenem Speicher“ als eigenes Risiko in Ihr Verzeichnis der Verarbeitungstätigkeiten und Ihre TOM nach Art. 32 DSGVO auf, und dokumentieren Sie die Bewertung dieses Vorfalls – auch wenn keine Meldung an die Aufsichtsbehörde nach Art. 33 DSGVO nötig ist. Bei Mittelständlern, die gerade KI-Agenten in Sandboxes einführen, ist das oft der schnellste Hebel für ein belastbares Audit.
Was sollten Sie jetzt tun?
- Kein Notfall-Patch nötig. Cloudflare hat den Fix plattformweit ausgerollt; auf Ihrer Seite gibt es nichts zu aktualisieren.
- Erfassen Sie, was Ihre Container auf die Platte schreiben. Listen Sie auf, welche Containers- oder Sandboxes-Workloads Datenbanken, Browserprofile, gecachte Tokens oder
.env-Dateien auf dem Root-Datenträger ablegen. - Rotieren Sie langlebige Secrets vorsorglich. Lief vor dem 7. September 2026 ein Container mit langlebigen API-Schlüsseln oder Datenbankpasswörtern auf der Platte, ist eine Rotation eine günstige Absicherung.
- Halten Sie Secrets aus dem Dateisystem heraus. Injizieren Sie Zugangsdaten zur Laufzeit aus einem Secrets-Manager mit kurzer TTL, statt sie in Images einzubacken oder auf die Platte zu schreiben.
- Verschlüsseln Sie sensible temporäre Daten. Müssen Workloads personenbezogene oder Finanzdaten lokal schreiben, verschlüsseln Sie sie mit einem Schlüssel pro Workload – dann sind Restblöcke für Dritte wertlos.
Häufige Fragen
Was war die Schwachstelle in Cloudflare Containers?
Cloudflare Containers und Sandboxes legten Container-Datenträger in einem gemeinsamen Thin-Provisioning-Pool ab, der so konfiguriert war, dass wiederverwendete 64-KiB-Blöcke nicht genullt wurden. Wurde der Container eines Kunden gelöscht, gingen seine Blöcke ungelöscht in den Pool zurück, und ein neuer Container eines anderen Workers-Paid-Kunden auf demselben Host konnte die Restdaten lesen.
Wurden Kundendaten gestohlen?
Cloudflare hat in der verfügbaren Disk-I/O-Telemetrie keine Hinweise auf böswillige Ausnutzung gefunden; die einzige Aktivität stammte von den Forschern und den eigenen Ingenieuren. Die Forscher geben an, dass ihre Skripte nur aggregierte Zählwerte statt Dateiinhalten lieferten. Ein Angreifer konnte zudem kein Opfer wählen und keinen Datenträger lesen, der noch an einem laufenden Container hing.
Müssen Cloudflare-Kunden etwas tun?
Nein. Laut Cloudflare ist die Schwachstelle behoben und die Bereinigung erfordert keine Kundenmaßnahmen. Wer langlebige Secrets oder sensible Datenbanken auf Container-Datenträgern gespeichert hat, kann diese Zugangsdaten vorsorglich rotieren.
Wann wurde die Lücke gemeldet und behoben?
Oren Yomtov von Accomplish meldete sie am 4. September 2026 über HackerOne. Cloudflare mergte noch am selben Tag einen Runtime-Fix, schloss den Rollout am 7. September ab, beendete die Snapshot-Bereinigung am 19. September und veröffentlichte die Offenlegung am 24. September 2026.
Ist der Vorfall nach DSGVO meldepflichtig?
Für die meisten Kunden nein: Cloudflare hat keinen Missbrauch festgestellt und keine Kundenmaßnahmen verlangt. Es empfiehlt sich aber, die Risikobewertung zu dokumentieren und zu prüfen, ob auf den betroffenen Containern personenbezogene Daten oder Zugangsdaten lagen.
Quellen
Cloudflare Blog — How Cloudflare addressed a cross-tenant data exposure vulnerability in Containers (24. September 2026)
BleepingComputer — Cloudflare fixes Containers cross-tenant flaw exposing customer data
The Hacker News — Cloudflare Fixes Flaw That Let One Container Read Another Customer's Leftover Disk Data