Ursache war die Konfiguration der gemeinsam genutzten Datenträger. Jeder Container erhält eine Festplatte, die über die Linux-Funktion Thin Provisioning aufgebaut wird und Speicher in Blöcken von 64 Kilobyte zuteilt. Wurde ein Container gelöscht, kehrten seine Blöcke in einen Pool zurück, den sich verschiedene Kundenkonten teilen.
Dieser Pool war so eingestellt, dass ein Block vor der Weitergabe an den nächsten Container nicht überschrieben wurde – obwohl das Löschen normalerweise die Voreinstellung ist. Schrieb ein neuer Container nur wenige Daten in einen wiederverwendeten Block, enthielt der Rest weiterhin Informationen des Vorgängers.
Um das nachzuweisen, schrieben die Forscher einen vier Kilobyte großen Block in ungenutzten Speicher und lasen anschließend den gesamten Block auf Rohdatenebene zurück. Die 60 nicht beschriebenen Kilobyte enthielten noch Bytes eines früheren Containers.
Cloudflare nennt als Fundstücke Verzeichnisstrukturen, Datenbankseiten und strukturell vollständige SQLite-Datenbanken. Die eigene Veröffentlichung der Forscher listet darüber hinaus Verzeichnislisten, Chromium-Browserprofile, .env-Dateien und Dateien mit Zugangsdaten auf und bezeichnet sie als Dateien anderer Kunden.
Nach Angaben der Forscher gaben ihre Analyseskripte ausschließlich Zählwerte und Formatprüfungen aus, nicht aber Dateiinhalte; das an Cloudflare übermittelte Material habe keine Namen, Kennungen, Zugangsdaten oder wiederhergestellten Inhalte Dritter enthalten. Cloudflare bestätigte, dass die gefundenen Daten vertraulich behandelt und nach der Übermittlung sicher gelöscht wurden. Dass sich damit fremde laufende Daten verändern oder Arbeitslasten stilllegen ließen, wiesen die Forscher nicht nach.
Die Behebung erfolgte in zwei Schritten. Zunächst aktivierte Cloudflare das Überschreiben neu vergebener Blöcke wieder, womit die beschriebene Methode nicht mehr funktionierte – die Forscher bestätigten am 14. September, dass ihr Proof of Concept wirkungslos geworden war. Blöcke, die bereits in laufende Container-Festplatten oder in den serverseitigen Zwischenspeicher vorbereiteter Image-Layer eingebunden waren, blieben davon jedoch unberührt; ein neuer Container hätte sie erben und auslesen können.
Deshalb zog Cloudflare zusätzlich sämtliche laufenden Container-Festplatten aus dem Verkehr und leerte die betreffenden Zwischenspeicher, wobei Server in verkehrsarmen Zeiten geleert und neu gestartet wurden. Diese Aufräumarbeiten endeten am 19. September, fünf Tage später machte das Unternehmen die Schwachstelle öffentlich.
Cloudflare suchte nach Hinweisen auf eine Ausnutzung durch Dritte: Aus dem Proof of Concept der Forscher und einem eigenen Nachbau des Angriffs entstanden Erkennungssignaturen, die gegen die aufbewahrten Aufzeichnungen der Festplattenaktivität liefen. Gefunden wurden nur die autorisierten Tests der Forscher und der eigenen Ingenieure; Belege für eine Nutzung dieser konkreten Methode durch andere gebe es nicht. Die Aussage bezieht sich allerdings auf die vorhandenen Aufzeichnungen – weder deren Zeitraum noch der Zeitpunkt, zu dem die unsichere Einstellung erstmals gesetzt wurde, geht aus der Darstellung hervor.
Die Forscher geben an, dieselbe Datenträgerkonfiguration habe auch Cloudflares Produkt Browser Run betroffen; Cloudflares Veröffentlichung nennt nur Containers und Sandboxes. Für das Team ist es nach eigener Zählung der sechste seit Juli veröffentlichte Ausbruch aus einer Code-Sandbox – nach Funden in Anthropics Claude Cowork und Claude Code, dem Kommandozeilenwerkzeug von Cursor, Docker und OpenAIs Codex.