Cloudflare Containers: Lücke gab Datenreste fremder Kunden frei

Wer Cloudflare Containers oder Cloudflare Sandboxes nutzt, sollte diese Meldung kennen: Über eine Lücke in der Speicherverwaltung konnte ein zahlender Kunde mit Workers-Paid-Konto Datenreste lesen, die Container anderer Kunden auf demselben Server hinterlassen hatten. Cloudflare hat die Schwachstelle nach eigenen Angaben flottenweit behoben, die Bereinigung wurde am 19. September 2026 abgeschlossen und am 24. September 2026 öffentlich gemacht. Nicht betroffen sind klassische Workers ohne Containers, Pages sowie alle, die Cloudflare nur als CDN, DNS oder Tunnel einsetzen.

Ein Notfall-Patch ist auf Kundenseite nicht nötig, Cloudflare verlangt ausdrücklich keine Konfigurationsänderung. Trotzdem lohnt heute eine kurze Prüfung: Wer vor dem 19. September Zugangsdaten, .env-Dateien oder Datenbanken im Dateisystem eines Containers abgelegt hat, sollte eine vorsorgliche Rotation dieser Geheimnisse im nächsten Wartungsfenster einplanen. Für Betreiber eigener Docker-Hosts ist der Fall zudem ein gutes Lehrstück, warum Secrets nicht auf die Container-Disk gehören.

Was ist passiert?

Am 4. September 2026 meldete der Sicherheitsforscher Oren Yomtov von Accomplish die Schwachstelle über das Bug-Bounty-Programm von Cloudflare auf HackerOne. Cloudflare und die Forscher haben am 24. September 2026 einen gemeinsam abgestimmten Bericht im Cloudflare-Blog veröffentlicht.

Technisch liegt die Ursache im Speicher-Unterbau. Jeder Container läuft bei Cloudflare in einer eigenen Firecracker-VM und bekommt eine beschreibbare Root-Disk, die über Linux Device Mapper Thin Provisioning (dm-thin) bereitgestellt wird. Dabei wird physischer Speicher erst dann zugeteilt, wenn tatsächlich geschrieben wird, und zwar in Blöcken von 64 KiB. Wird ein Container gelöscht, wandern seine Blöcke zurück in einen Pool, aus dem die Container mehrerer Kundenkonten bedient werden.

Der betroffene Pool war mit der Option skip_block_zeroing konfiguriert. Damit überspringt dm-thin das Nullen neu zugeteilter Blöcke, obwohl das Nullen normalerweise der Standard ist. Schreibt ein neuer Container nur 4 KiB in einen wiederverwendeten 64-KiB-Block, bleiben die übrigen 60 KiB mit den Daten des Vorbesitzers gefüllt. Der Proof of Concept schrieb gezielt kleine Blöcke in freien Bereich des ext4-Dateisystems und las anschließend das Rohgerät /dev/vdc komplett aus.

Laut Cloudflare fanden die Forscher auf 18 von 24 Platzierungen und auf 20 von 22 zugrunde liegenden Servern auf vier Kontinenten fremde Datenreste. Cloudflare nennt Verzeichnisstrukturen, Datenbankseiten und strukturell vollständige SQLite-Datenbanken. Der Bericht von Accomplish spricht zusätzlich von Chromium-Profilen, .env-Dateien und Credential-Dateien anderer Kunden. Nach Angaben beider Seiten haben die Forscher nur Zählungen und Formatprüfungen ausgewertet, keine Inhalte weitergegeben und die geborgenen Daten sicher gelöscht.

Die Behebung lief in zwei Stufen:

4. bis 7. September: skip_block_zeroing wurde flottenweit entfernt, neu zugeteilte Blöcke werden wieder genullt. Am 14. September bestätigten die Forscher, dass ihr Proof of Concept nicht mehr funktioniert.
Bis 19. September: Weil bereits zugeordnete Blöcke in laufenden Container-Disks und im Cache vorbereiteter Image-Layer nicht nachträglich bereinigt wurden, hat Cloudflare alle laufenden Container-Disks ausgemustert, Hosts in ruhigen Zeiten geleert, VMs neu gestartet und die Image-Caches geleert.

Wer ist betroffen?

Betroffen waren nach Cloudflare-Angaben Kunden, die Cloudflare Containers oder das darauf aufbauende Cloudflare Sandboxes genutzt haben. Sandboxes ist gerade für das Ausführen von nicht vertrauenswürdigem Code gedacht, etwa Code von KI-Agenten. Accomplish nennt zusätzlich Browser Run als betroffen, weil es dieselbe Disk-Implementierung nutzt. Der Cloudflare-Beitrag erwähnt Browser Run nicht, dieser Punkt ist also nur durch die Forscher belegt.

Potenziell offengelegt: Daten, die Container vor dem Fix auf ihre Root-Disk geschrieben und später durch Löschen freigegeben haben.
Nicht offengelegt: aktiv eingebundene Disks laufender Workloads. Ein Angreifer konnte laut Cloudflare kein bestimmtes Opfer, keinen bestimmten Host und keine bestimmten Daten auswählen.
Nicht betroffen: Nutzer, die weder Containers noch Sandboxes noch Browser Run einsetzen.

Offen bleibt der Zeitraum. Cloudflare nennt nicht, seit wann die unsichere Pool-Einstellung aktiv war und wie weit die ausgewerteten Disk-I/O-Aufzeichnungen zurückreichen. Wie lange Daten grundsätzlich lesbar waren, lässt sich aus den Quellen daher nicht ableiten.

Wie kritisch ist das?

Es handelt sich um einen mandantenübergreifenden Datenabfluss, also einen Bruch der Tenant-Isolation. Eine Remote Code Execution, eine Manipulation fremder Daten oder ein Ausfall fremder Workloads wurde nicht nachgewiesen. Das senkt die Einstufung, macht die Lücke aber nicht harmlos: Wer als Angreifer genug Container startet, bekommt zufällige, aber reale Fremddaten, und dazu können Zugangsdaten gehören.

Cloudflare hat nach eigener Aussage Erkennungssignaturen aus dem Proof of Concept gebaut und die aufbewahrte Disk-I/O-Telemetrie durchsucht. Gefunden wurden nur die autorisierten Tests der Forscher und der eigenen Ingenieure. Eine missbräuchliche Ausnutzung ist damit nicht belegt. Diese Aussage gilt allerdings nur für den Zeitraum, den die Telemetrie abdeckt, und der ist nicht veröffentlicht. Eine CVE-Nummer oder einen CVSS-Wert nennen die Quellen nicht.

Unsere Einordnung: kein Grund für hektische Nachtaktionen, aber ein Fall für eine geplante Prüfung in dieser Woche, wenn in Containers oder Sandboxes echte Zugangsdaten verarbeitet wurden.

Was sollten Admins jetzt tun?

Inventar prüfen: Im Cloudflare-Dashboard und in den wrangler-Konfigurationen aller Konten nachsehen, ob Containers, Sandboxes oder Browser Run genutzt wurden, und die Nutzung zeitlich vor dem 19. September 2026 eingrenzen.
Klären, welche Daten diese Container auf ihre Disk geschrieben haben: .env-Dateien, API-Schlüssel, Cloud-Credentials, SSH-Schlüssel, SQLite-Datenbanken, Browser-Profile mit Sitzungs-Cookies.
Vorsorglich rotieren, was dort lag. Cloudflare verlangt das nicht, es ist unsere Empfehlung, weil der Expositionszeitraum nicht veröffentlicht ist und Rotation wenig kostet.
Bei Sandboxes für KI-Agenten prüfen, welche Tokens die Agenten im Dateisystem zwischengespeichert haben, etwa Git- oder Paketregistry-Tokens.
Geheimnisse künftig über Laufzeit-Bindings oder einen Secret-Store injizieren, statt sie in Images oder Dateien auf der Container-Disk abzulegen.
Sitzungen und Browser-Profile, die in Browser Run oder Sandboxes erzeugt wurden, als potenziell kompromittiert behandeln und betroffene Web-Sitzungen serverseitig abmelden.
Den Vorfall in der eigenen Risikodokumentation für Auftragsverarbeiter vermerken und bei personenbezogenen Daten mit dem Datenschutzbeauftragten die Meldepflicht prüfen.

Für eigene Linux- und Docker-Hosts lohnt ein Seitenblick. Wer LVM-Thin-Pools für Container- oder VM-Speicher nutzt, kann den Zeroing-Modus mit lvs -o name,zero abfragen. Laut lvmthin-Dokumentation werden beim späteren Umstellen von aus auf an bereits bereitgestellte Blöcke nicht nachträglich genullt, genau das Muster, das Cloudflare zur zweiten Bereinigungsstufe gezwungen hat.

Auf Docker-Hosts mit mehreren Kunden oder Abteilungen keine sensiblen Daten in den beschreibbaren Container-Layer schreiben, sondern in dedizierte, verschlüsselte Volumes.
Docker Secrets oder einen Secret-Manager nutzen, die Geheimnisse als tmpfs im Arbeitsspeicher bereitstellen statt auf Disk.
Beim Wiederverwenden von Datenträgern, LUNs oder Volumes zwischen Mandanten sicher löschen oder mit wechselnden Schlüsseln verschlüsseln.

Einordnung für Unternehmen

Der Fall zeigt, dass Mandantentrennung bei Container- und Serverless-Plattformen nicht nur an Namespaces, VMs und Netzwerkgrenzen hängt, sondern auch an unscheinbaren Speicheroptionen. Eine einzige Performance-Optimierung im Thin-Pool reichte, um trotz eigener Firecracker-VM pro Container Daten zwischen Kunden durchsickern zu lassen. Für KMU, die Code bei einem Anbieter ausführen lassen, heißt das: Der Anbieter isoliert, aber nie perfekt. Was wirklich schutzbedürftig ist, gehört nicht unverschlüsselt in das Dateisystem eines kurzlebigen Containers.

Positiv ist die Reaktion: Cloudflare hatte binnen Stunden einen Fix gemerged, hat auch die Altlasten in bestehenden Disks und Caches bereinigt und den Vorfall gemeinsam mit den Forschern transparent beschrieben. Kritisch bleibt die fehlende Angabe zum Expositionszeitraum. Wer Plattformen dieser Art bewertet, sollte bei Anbietern gezielt nachfragen, wie freigegebener Speicher vor der Wiederverwendung bereinigt wird und wie lange Telemetrie für forensische Auswertungen aufbewahrt wird. Für die eigene Infrastruktur gilt dieselbe Lehre: Secrets zur Laufzeit injizieren, Volumes trennen und Datenträger vor der Weitergabe bereinigen.

Passende Anleitungen auf S-EDV

Docker Compose absichern: Secrets, Healthchecks und Non-Root: wie Geheimnisse aus Umgebungsvariablen und Images herauskommen.
Infisical mit Docker für Secrets-Management: zentraler Secret-Store, der Zugangsdaten zur Laufzeit ausliefert und Rotation erleichtert.
Gitleaks als Secret-Scanner mit Docker: findet Schlüssel, die versehentlich in Repositories oder Images gelandet sind.

Was ist passiert?

Wer ist betroffen?

Wie kritisch ist das?

Was sollten Admins jetzt tun?

Einordnung für Unternehmen

Passende Anleitungen auf S-EDV

Quellen

Weiter lesen

Harness Open Source mit Docker installieren: End-to-End-DevOps-Plattform mit Git, CI/CD und Artifact-Registry

Renovate mit Docker installieren: Automatisierter Dependency-Update-Bot für GitHub, GitLab und Gitea

Jenkins mit Docker installieren: Der bewährteste Open-Source-CI/CD-Server