Cloudflare löscht wiederverwendete Container-Datenträger nach Datenleck zwischen Mandanten

Cloudflare hat eine Schwachstelle bei der Speicherisolierung in Cloudflare Containers behoben. Sie ermöglichte es, dass der Workload eines Kunden Datenträgerfragmente auslesen konnte, die ein anderer Mandant auf derselben physischen Infrastruktur hinterlassen hatte.

Betroffen war auch Cloudflare Sandboxes, ein auf Containers basierender Dienst zum Ausführen nicht vertrauenswürdigen Codes, etwa von KI-Agenten generierter Programme. Die Schwachstelle legte zurückgebliebene Anwendungsdaten offen, nicht aber gerade eingebundenen Speicher. Tests zeigten jedoch, dass sich auf einem Großteil der untersuchten Produktivsysteme Datenblöcke wiederherstellen ließen.

Cloudflare spielte die Korrekturen automatisch ein und schloss die Bereinigung seiner Infrastruktur am 19. September 2026 ab. Kunden müssen nichts unternehmen.

Wiederverwendete Datenblöcke überschritten die Mandantengrenze

Cloudflare Containers führt containerisierte Workloads für Kunden mit Workers-Paid-Konten aus. Typische Einsatzgebiete sind Backend-Anwendungen, Dienste zur Auftragsverarbeitung und isolierte Umgebungen zur Codeausführung.

Cloudflare entscheidet, wo die einzelnen Container ausgeführt werden. Zugleich nutzen mehrere Kundenkonten dieselben Server und Speicherressourcen des Anbieters. Dieses Modell erfordert eine strikte Trennung: nicht nur zwischen aktiven Workloads, sondern auch dann, wenn Speicher freigegeben und später einem anderen Kunden zugewiesen wird.

Der Sicherheitsforscher Oren Yomtov von Accomplish meldete die Schwachstelle am 4. September über das Bug-Bounty-Programm von Cloudflare, das BleepingComputer als HackerOne identifizierte.

Die Schwachstelle trat beim Löschen eines Containers auf. Seine physischen Datenträgerblöcke wurden einem gemeinsam genutzten Pool zurückgegeben, aus dem später Container anderer, nicht verbundener Konten Speicher erhalten konnten. Der Pool war so konfiguriert, dass die Blöcke vor der Wiederverwendung nicht gelöscht wurden – obwohl das normalerweise die Standardeinstellung war.

Die Zuweisung eines Blocks an einen neuen Mandanten garantierte daher nicht, dass jedes Byte zuvor gelöscht worden war. Bereiche, die der neue Workload nicht überschrieb, konnten weiterhin Daten des vorherigen Nutzers enthalten.

Ein Schreibvorgang mit 4 KiB legte den Rest eines 64-KiB-Blocks offen

Der betroffene Speicher nutzte Linux Thin Provisioning und teilte die Speicherkapazität in Blöcke zu je 64 KiB auf. Beim Thin Provisioning wird logischer Speicher nach Bedarf physischer Kapazität zugeordnet. So muss nicht im Voraus eine vollständige Speicherzuweisung reserviert werden.

Die Forscher demonstrierten eine direkte Folge der nicht aufeinander abgestimmten Größen von Speicherzuweisung und Schreibvorgang: Ein neu erstellter Container konnte 4 KiB in einen ansonsten ungenutzten Speicherbereich schreiben und anschließend über den direkten Zugriff auf den Datenträger den gesamten physischen 64-KiB-Block auslesen.

Der neue Schreibvorgang ersetzte die ersten 4 KiB. Die übrigen 60 KiB konnten weiterhin Daten eines gelöschten Containers enthalten, dem derselbe physische Block zuvor zugewiesen worden war.

Dabei handelte es sich nicht um herkömmlichen Dateizugriff über das eingebundene Dateisystem eines anderen Mandanten. Stattdessen durchsuchten die Angreifer den wieder freigegebenen Speicher unterhalb dieser Abstraktionsebene nach erkennbaren Strukturen in den zurückgebliebenen Bytes.

Cloudflare zufolge hätte eine erfolgreiche Ausnutzung die Mandantenisolierung verletzt. Zu den potenziell offengelegten Daten gehörten:

• Metadaten und Verzeichnisstrukturen des Dateisystems
• Datenbankseiten und vollständige SQLite-Datenbankstrukturen
• Anwendungsdaten
• Chromium-Browserprofile
• .env-Dateien
• Dateien mit Zugangsdaten

Die Ergebnisse zeigen, dass sensible Informationen nicht unbedingt als vollständige, gewöhnliche Datei vorliegen müssen, um nützlich zu sein. Datenbankseiten, Konfigurationsfragmente oder Verzeichniseinträge können selbst dann Geheimnisse und betriebliche Details preisgeben, wenn sie nur teilweise wiederhergestellt werden.

Tests in der Produktivumgebung fanden Rückstände auf den meisten untersuchten Systemen

Die Forscher entdeckten in 18 von 24 Container-Platzierungen Datenreste. Auch auf 20 der 22 in den Tests untersuchten zugrunde liegenden Rechner oder Knoten fanden sie solche Spuren. Die Systeme erstreckten sich über vier Kontinente, wie aus Berichten zu Cloudflares Offenlegung und den Ergebnissen der Forscher hervorgeht.

Cloudflare zufolge umfassten die wiederhergestellten Blöcke Verzeichnisstrukturen, Datenbankseiten und strukturell vollständige SQLite-Datenbanken. Die Forscher nannten außerdem Browserprofile, Umgebungsdateien und Dateien mit Zugangsdaten unter den erkennbaren Formaten.

Ihre Analysetools erstellten aggregierte Zählungen und prüften Datenformate, ohne Dateiinhhalte zu sammeln. Nach eigenen Angaben enthielt ihre Meldung an Cloudflare weder Namen und Kennungen Dritter noch Zugangsdaten oder wiederhergestellte Kundeninhalte. Alle wiederhergestellten Daten hielten sie vertraulich und löschten sie nach der Meldung sicher.

Cloudflare zufolge wurden bei der autorisierten Untersuchung keine echten Kundendaten offengelegt. Die Forscher erklärten unabhängig davon, während der Tests Datenreste wiederhergestellt zu haben. Die Aussagen beziehen sich auf unterschiedliche Aspekte der Untersuchung: Die Tests belegten, dass alte Datenstrukturen zugänglich geblieben waren; die Forscher geben an, keine identifizierbaren Inhalte Dritter aufbewahrt oder übermittelt zu haben.

Die Schwachstelle ermöglichte die Offenlegung von Daten, nicht die Kontrolle über andere Workloads

Die nachgewiesene Auswirkung beschränkte sich auf die Vertraulichkeit. Die Forscher zeigten nicht, dass ein Angreifer aktive Dateien eines anderen Kunden verändern, einen Dienst unterbrechen oder die Kontrolle über den Container des Opfers übernehmen konnte.

Auch ließ sich ein Datenträger nicht auslesen, solange er aktiv in einen anderen Workload eingebunden war. Eine Ausnutzung setzte voraus, dass physische Blöcke freigegeben und über den gemeinsam genutzten Speicherpool neu zugewiesen wurden.

Ebenso konnten Angreifer kein bestimmtes Opfer auswählen. Cloudflare bestimmte die Platzierung der Container, und welche wiederverwendeten Blöcke einem neu gestarteten Workload zur Verfügung standen, hing von den Zuweisungsentscheidungen der Infrastruktur ab. Ein Angreifer konnte also nach Datenresten suchen, aber keinen Speicher anfordern, der zuvor einer bestimmten Organisation zugewiesen war.

Diese Einschränkung macht die Methode weniger zielgenau, ändert aber nichts an der Sensibilität möglicher Funde. Geheimnisse in .env-Dateien, Zugangsdatenspeichern oder Datenbankseiten können wertvoll sein – unabhängig davon, welcher Mandant sie ursprünglich angelegt hat.

Die Forscher erklärten zudem, dass Cloudflare Browser Run dieselbe Datenträgerkonfiguration nutzte. In Cloudflares Offenlegung wurden Containers und Sandboxes als betroffen genannt, Browser Run jedoch nicht. Daher ist unklar, ob Cloudflare Browser Run als eigenständig betroffen einstuft oder ob für den Dienst zusätzliche, spezifische Maßnahmen erforderlich waren.

Cloudflare fand außerhalb der Tests keine Hinweise auf eine Ausnutzung

Nachdem Cloudflare die Schwachstelle reproduziert hatte, erstellte das Unternehmen auf Grundlage des Proof of Concept der Forscher und eigener Tests Erkennungssignaturen. Anschließend durchsuchte es gespeicherte Datenträgeraktivitätsprotokolle nach passenden Verhaltensmustern.

Dabei fand das Unternehmen nur die autorisierten Aktivitäten der Forscher und der Cloudflare-Ingenieure. Die Überprüfung von Protokollen, Telemetriedaten und historischen Informationen ergab Berichten zufolge keine Hinweise darauf, dass andere die gleiche Methode zur Offenlegung von Kundendaten eingesetzt hatten.

Aus den verfügbaren Informationen geht allerdings nicht hervor, wie weit die gespeicherten Protokolle zurückreichten. Cloudflare legte auch nicht offen, wann die unsichere Konfiguration ohne Nullsetzung eingeführt worden war. Wie lange Datenreste insgesamt möglicherweise wiederherstellbar waren, ist daher unbekannt.

Kunden wurden keine öffentlichen Indicators of Compromise zur Verfügung gestellt, nach denen sie suchen könnten. Da die relevanten Nachweise in Cloudflares Speicherinfrastruktur und Platzierungssystemen lagen, haben einzelne Nutzer möglicherweise nur eingeschränkte Möglichkeiten festzustellen, ob ihre gelöschten Blöcke jemals neu zugewiesen wurden.

Die Anpassung der Speicherzuweisung war nur der erste Schritt

Zunächst aktivierte Cloudflare wieder die Nullsetzung neu zugewiesener Blöcke. Dadurch wurde sichergestellt, dass Speicher, der nach der Korrektur vergeben wurde, vor dem Zugriff durch einen anderen Mandanten gelöscht wurde.

Am 14. September bestätigten die Forscher, dass ihr Proof of Concept nicht mehr funktionierte. Die Änderung der Zuweisungsrichtlinie entfernte jedoch nicht alle historischen Zuordnungen, die bereits auf der Plattform vorhanden waren.

Blöcke konnten weiterhin mit Datenträgern laufender Container verknüpft sein. Auch vorbereitete Image-Layer und zwischengespeicherte Snapshots konnten ältere Zuordnungen bewahren. Cloudflare setzte daher alle aktiven Container-Datenträger außer Betrieb und leerte die betreffenden Caches. Dazu fuhr das Unternehmen die Server während ruhigeren Betriebszeiten kontrolliert herunter und startete sie neu.

Diese Bereinigung schloss Cloudflare am 19. September 2026 ab. Die Maßnahmen erfolgten innerhalb der Cloudflare-Infrastruktur. Kunden müssen daher weder Anwendungen patchen noch Container-Images austauschen oder ihre Konfiguration ändern, um von der Korrektur zu profitieren.

Es wurde weder eine CVE-Kennung noch eine formelle Schweregradbewertung veröffentlicht. Am treffendsten lässt sich der Vorfall als Verletzung der Vertraulichkeit zwischen Mandanten durch potenziell sensible Datenreste einordnen – nicht als Übernahme eines Hosts oder destruktiver Ausbruch aus einem Container.

Die Forscher bezeichneten den Vorfall als ihren sechsten veröffentlichten Ausbruch aus einer Code-Sandbox seit Juli. Zuvor hatten sie Untersuchungen zu Anthropic Claude Cowork und Claude Code, dem Kommandozeilen-Tool von Cursor, Docker und OpenAI Codex veröffentlicht. In diesem Fall bestand die nachgewiesene Fähigkeit jedoch darin, Inhalte wiederverwendeter Datenträger auszulesen – nicht darin, beliebige Kontrolle über einen anderen Mandanten oder den Cloudflare-Host zu erlangen.