Cloudflare-Container: Wiederverwendete Speicherblöcke verrieten Datenreste fremder Kunden

Cloudflare hat in seinem Dienst Containers eine Lücke geschlossen, über die zahlende Kunden Datenreste fremder Konten lesen konnten. Ein Sicherheitsforscher fand auf 18 von 24 getesteten Platzierungen übrig gebliebene Dateien, darunter vollständige SQLite-Datenbanken. Die Ursache lag in einer einzigen Einstellung des Linux-Speichersystems.

drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen

Oren Yomtov schrieb 4 KiB in einen freien Bereich seines eigenen Cloudflare-Containers und bekam einen Speicherblock zugeteilt, dessen übrige 60 KiB Daten fremder Kunden enthielten. Der Forscher des Sicherheitsunternehmens Accomplish meldete den Fund am 4. September über das Bug-Bounty-Programm von Cloudflare bei HackerOne. Am 24. September legte Cloudflare den Vorfall in einem ausführlichen Blogbeitrag offen.^[1]

Das Wichtigste in Kürze

• Über Cloudflare Containers und die darauf aufbauenden Sandboxes konnte jedes Konto im Tarif Workers Paid Datenreste anderer Kunden auf demselben Server auslesen.
• Die Ursache war die Linux-Option skip_block_zeroing: Wiederverwendete Speicherblöcke von 64 KiB gingen ungenullt an den nächsten Container.
• Cloudflare schloss die Lücke bis zum 19. September vollständig und fand in der eigenen Telemetrie keine Hinweise auf einen Missbrauch.
• Kunden müssen laut Cloudflare nichts unternehmen. Zugangsdaten aus Container-Dateien auszutauschen, lohnt sich trotzdem.

Was konnte ein fremdes Konto auf Cloudflares Servern lesen?

Cloudflare Containers führt Container-Images im weltweiten Netz des Anbieters aus, gesteuert über dessen Serverless-Plattform Workers. Die Sandboxes setzen auf Containers auf und führen Code isoliert aus, den etwa KI-Agenten erzeugen. Mehrere Kunden teilen sich dabei physische Server. Jede Container-Instanz erhält eine eigene Root-Disk, deren Blöcke aus einem gemeinsamen Speicherpool stammen. Löschte ein Kunde seinen Container, flossen die Blöcke in den Pool zurück, aus dem auch Container anderer Konten ihre Disks bezogen.^[1]

Den Rückfluss machte sich Yomtov mit einem gezielten Schreibmuster zunutze. In jeden 64-KiB-Bereich, den das Dateisystem ext4 als frei führte, schrieb er einen einzelnen Block von 4 KiB. Das System teilte ihm dafür jeweils einen gebrauchten Block zu, ohne den Rest vorher zu nullen. Laut Cloudflare tauchten so Verzeichnislisten, Datenbankseiten, vollständige SQLite-Datenbanken und Dateisystem-Metadaten auf. Allein auf sechs Produktions-Platzierungen zählten die Forscher rund 2.700 fremde Verzeichniseinträge.

Einen bestimmten Kunden konnte ein Angreifer nach Cloudflares Darstellung nicht gezielt ansteuern. Welche Daten auf einem Block lagen, entschied der Zufall. Reste fanden sich außerdem nicht auf jedem Host. Die Skripte der Forscher lieferten nur Zählwerte, echte Kundendaten sahen Yomtov und sein Team nicht ein.

Warum lagen die alten Daten noch auf den Blöcken?

Cloudflare verwaltet die Container-Disks per Thin Provisioning über den Device Mapper des Linux-Kernels, kurz dm-thin. Das Verfahren vergibt Speicher erst beim ersten Schreiben und überschreibt einen frisch zugeteilten Block standardmäßig mit Nullen. Die Option skip_block_zeroing schaltet genau diesen Schritt ab.^[2] Auf den betroffenen Pools von Cloudflare war die Option aktiv.

Das Nullen kostet Schreibleistung, weil der Server jeden neuen Block vollständig überschreiben muss, bevor ein Container darauf zugreift. Warum die Option aktiv war, erklärt Cloudflare nicht. Die Kernel-Dokumentation empfiehlt für Pools ohne Nullung größere Blöcke. Die Empfehlung spricht für Tempo als Motiv.

Dieselbe Abwägung ging schon einmal schief. Ende 2013 konnten Kunden des US-Hosters DigitalOcean Daten ihrer Vorgänger von den SSDs virtueller Server lesen. Der Anbieter hatte das Löschen beim Zerstören eines Servers aus Leistungsgründen zur Option gemacht und die API-Kunden über die geänderte Voreinstellung nicht informiert. Nach öffentlicher Kritik kehrte DigitalOcean zur Löschung als Standard zurück.^[3]

Für Cloudflare bedeutet der Fall die zweite Mandanten-Lücke binnen weniger Wochen. Im August las ein Forscherteam per Spectre-Angriff auf Cloudflare Workers das JWT eines fremden Kunden aus. Beide Fälle betreffen die Trennung von Kunden auf geteilter Hardware, einmal im Prozessor und einmal auf dem Datenträger. Wie tief solche Fehler sitzen können, zeigte zuletzt die Linux-Lücke Januscape in KVM, über die ein Gast bis auf den Host durchbrach.

Was sollten Unternehmen in der DACH-Region jetzt prüfen?

Cloudflare deaktivierte die Option in der gesamten Flotte, musterte alle vor dem Fix angelegten Container-Disks aus und löschte zwischengespeicherte Image-Snapshots. Kunden müssen laut Anbieter nichts unternehmen.^[1] In der historischen Telemetrie fand Cloudflare nur Zugriffe der Forscher und eigener Techniker. Die Auswertung reicht allerdings nur so weit, wie die vorhandenen Aufzeichnungen zurückgehen.

Datenschutzrechtlich bleibt der Kunde als Verantwortlicher in der Pflicht. Cloudflare arbeitet als Auftragsverarbeiter nach Artikel 28 DSGVO. Eine Meldung an die Aufsichtsbehörde nach Artikel 33 setzt eine Verletzung des Schutzes personenbezogener Daten voraus, Belege für einen Abfluss nennt Cloudflare keine. Den Vorfall intern zu dokumentieren und die Risikobewertung zu aktualisieren, empfiehlt sich trotzdem, besonders für Unternehmen im Geltungsbereich von NIS2.

Heikel bleiben die Sandboxes, weil dort KI-Agenten mit Schlüsseln und Tokens arbeiten. Einen eigenen Linux-Container pro Agent hält Cloudflare inzwischen selbst für zu teuer, die Sandboxes bietet der Anbieter trotzdem weiter an. Für Container-Workloads auf geteilter Infrastruktur lohnen vier Prüfungen:

• Tauschen Sie gerne API-Schlüssel und Passwörter aus, die vor dem 7. September in .env-Dateien oder Datenbanken auf Cloudflare-Containern lagen.
• Legen Sie Zugangsdaten als verschlüsselte Secrets der Plattform ab statt als Datei auf der Container-Disk.
• Verschlüsseln Sie sensible Daten auf Anwendungsebene, damit Reste auf fremden Blöcken unlesbar bleiben.
• Lassen Sie sich im Vertrag zur Auftragsverarbeitung zusichern, wie der Anbieter gelöschte Datenträger bereinigt. Die Frage gehört auch in jeden Webhosting-Vergleich.

Welche Schutzmaßnahmen sich im Mittelstand bewährt haben, fassen die Cybersecurity-Grundlagen zusammen.

FAQ: Cloudflare-Container-Lücke

Quellen

[1] Cloudflare: „How Cloudflare addressed a cross-tenant data exposure vulnerability in Containers“ (24. September 2026)

[2] Linux-Kernel-Dokumentation: „Thin provisioning“, Device Mapper

[3] DigitalOcean: „Transparency Regarding Data Security“ (29. Dezember 2013)

Mehr Newshunger?

• Cloudflare Workers: Ein Spectre-Angriff las das JWT eines fremden Kunden
• 16 Jahre unentdeckt: Sicherheitslücke „Januscape“ im Linux-Kernel
• GitLab-Lücke CVE-2026-85706: Eine Anfrage liest jede Datei vom Server
• IONOS verschlüsselt Cloud-VMs bis in den Arbeitsspeicher
• Datenleck bei Lidl: Warum der Dienstleister das eigentliche Einfallstor war
• „Ich will die Details nicht“: Warum ein Postmortem nach der Panne oft nichts ändert