Wprowadzenie do problemu / definicja
Cloudflare poinformował o usunięciu podatności w usługach Containers i Sandboxes, która mogła naruszać izolację między klientami współdzielącymi tę samą infrastrukturę fizyczną. Problem dotyczył wycieku danych rezydualnych, czyli pozostałości po wcześniejszych obciążeniach zapisanych w blokach dyskowych, które po ponownym przydzieleniu nowemu tenantowi nie zostały w pełni wyzerowane.
To szczególnie istotny typ błędu w środowiskach wielodzierżawnych, gdzie bezpieczeństwo opiera się na założeniu, że dane jednego klienta pozostają całkowicie odseparowane od zasobów innych użytkowników platformy.
W skrócie
Luka mogła umożliwić klientowi korzystającemu z planu Workers Paid odczytanie fragmentów danych należących wcześniej do innych klientów uruchamiających kontenery na tym samym hoście. Źródłem problemu był błąd w warstwie pamięci masowej: współdzielona pula bloków zwracała ponownie używane bloki 64 KiB bez pełnego czyszczenia ich zawartości.
Badacze wykazali możliwość odzyskania metadanych systemu plików, struktur katalogów, stron baz danych SQLite, plików konfiguracyjnych oraz innych artefaktów aplikacyjnych. Cloudflare podał, że nie znalazł dowodów na aktywne wykorzystanie podatności przeciwko klientom, a pełne działania naprawcze zakończono 19 września 2026 roku.
Kontekst / historia
Podatność została zgłoszona 4 września 2026 roku przez badacza bezpieczeństwa Orena Yomtova z firmy Accomplish w ramach programu bug bounty. Problem obejmował środowiska Cloudflare Containers oraz Cloudflare Sandboxes, przy czym druga z tych usług korzysta z tej samej architektury kontenerowej.
Z punktu widzenia bezpieczeństwa chmury był to incydent o dużym znaczeniu, ponieważ dotyczył jednej z podstawowych gwarancji modelu multi-tenant: ścisłej separacji danych pomiędzy tenantami. Nawet bez przejęcia sesji, wykonania kodu czy modyfikacji danych, sam odczyt pozostałości z nośnika po innym kliencie stanowi naruszenie granicy izolacji.
Analiza techniczna
Źródłem problemu była konfiguracja współdzielonej puli storage wykorzystywanej przez cienko alokowane wolumeny kontenerów. Gdy kontener usuwał swój dysk root, fizyczne bloki wracały do wspólnej puli i mogły zostać przydzielone kolejnemu obciążeniu należącemu do innego klienta. Krytyczny błąd polegał na pominięciu pełnego zerowania bloków przed ich ponownym użyciem.
Opisany scenariusz ataku nie wymagał bezpośredniego dostępu do dysku ofiary ani przejęcia hosta. Badacze pokazali metodę polegającą na zapisaniu niewielkiego fragmentu danych o rozmiarze 4 KiB w nieużywanym regionie nowo uruchomionego dysku kontenera. Taka operacja powodowała przydzielenie fizycznego bloku 64 KiB ze wspólnej puli. Ponieważ czyszczenie było wyłączone, tylko nadpisane 4 KiB zawierały nowe dane, a pozostałe 60 KiB mogły nadal przechowywać zawartość należącą do poprzedniego klienta.
W praktyce oznaczało to możliwość odczytu danych rezydualnych z obszarów, których nowy kontener sam wcześniej nie zapisał. Według opisu technicznego w odzyskanych materiałach znajdowały się między innymi listingi katalogów, kompletne struktury systemu plików, strony baz SQLite, profile Chromium, pliki .env oraz pliki poświadczeń. Obserwacja takich artefaktów na wielu testowanych przydziałach wskazuje, że problem nie miał wyłącznie teoretycznego charakteru.
Cloudflare usunął ustawienie odpowiedzialne za pomijanie zerowania bloków, wycofał istniejące dyski kontenerów i wyczyścił cache snapshotów, które mogły zachowywać stare mapowania. Poprawki zostały wdrożone po stronie infrastruktury i nie wymagały działań po stronie klientów.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem tej klasy podatności jest naruszenie poufności danych w środowisku współdzielonym. Zagrożenie obejmuje nie tylko treść plików, ale również metadane, które często mają dużą wartość operacyjną: nazwy katalogów, struktury projektów, ślady używanych frameworków, fragmenty baz danych czy artefakty środowisk uruchomieniowych.
Ryzyko rośnie szczególnie wtedy, gdy w kontenerach przechowywane są:
- pliki
.envz sekretami aplikacyjnymi, - tokeny API i poświadczenia dostępowe,
- lokalne bazy SQLite,
- profile przeglądarek i sesje automatyzacji,
- dane tymczasowe backendów oraz zadań przetwarzających.
Choć Cloudflare nie odnotował dowodów na rzeczywiste wykorzystanie luki przeciwko klientom, sama możliwość odczytu obcych danych z wcześniej używanych bloków oznacza istotne osłabienie modelu izolacji. W środowiskach chmurowych taki błąd może mieć konsekwencje regulacyjne, kontraktowe i operacyjne, zwłaszcza dla organizacji przetwarzających dane klientów, tajemnice przedsiębiorstwa lub informacje objęte wymogami compliance.
Rekomendacje
Incydent pokazuje, że izolacja logiczna nie eliminuje całkowicie ryzyka błędów w warstwie storage. Organizacje korzystające z platform kontenerowych i serverless powinny ograniczać ilość wrażliwych danych zapisywanych lokalnie oraz zakładać, że nośniki tymczasowe nie są miejscem do trwałego przechowywania sekretów.
- Ograniczać przechowywanie sekretów na lokalnych dyskach kontenerów i korzystać z dedykowanych systemów zarządzania sekretami.
- Minimalizować ilość danych tymczasowych zapisywanych lokalnie przez aplikacje oraz szyfrować je, jeśli ich zapis jest konieczny.
- Weryfikować, czy dostawca chmury stosuje pełne zerowanie bloków, bezpieczne usuwanie snapshotów i odpowiednie mechanizmy ponownego użycia nośników.
- Przeglądać architekturę aplikacji pod kątem bibliotek i komponentów automatycznie zapisujących cache, profile użytkownika, artefakty debugowania lub lokalne bazy.
- Monitorować nietypowe operacje niskopoziomowe na urządzeniach blokowych tam, gdzie platforma zapewnia odpowiednią widoczność telemetryczną.
Podsumowanie
Przypadek Cloudflare Containers pokazuje, że bezpieczeństwo chmury zależy nie tylko od separacji procesów i uprawnień, ale również od poprawnej obsługi cyklu życia bloków dyskowych. Luka nie umożliwiała modyfikacji danych ofiary ani dostępu do aktywnie podłączonych dysków, jednak naruszała jedną z kluczowych granic bezpieczeństwa w architekturze multi-tenant: poufność danych pochodzących z wcześniejszych obciążeń.
Szybka reakcja dostawcy i brak oznak aktywnego nadużycia ograniczają skalę incydentu, ale techniczny charakter błędu sprawia, że jest to ważny sygnał ostrzegawczy dla całego rynku chmury i platform kontenerowych.
Źródła
- Cloudflare fixes Containers cross-tenant flaw exposing customer data — https://www.bleepingcomputer.com/news/security/cloudflare-fixes-containers-cross-tenant-flaw-exposing-customer-data/
- How Cloudflare addressed a cross-tenant data exposure vulnerability in Containers — https://blog.cloudflare.com/containers-cross-tenant-vulnerability/
- Posts tagged „Vulnerabilities” — Cloudflare Blog — https://blog.cloudflare.com/tag/vulnerabilities/