Cloudflare mengungkap kerentanan isolasi pada layanan Containers dan Sandboxes yang secara teori memungkinkan satu pelanggan membaca sisa data dari workload pelanggan lain di host fisik yang sama. Perusahaan mengatakan celah tersebut sudah diperbaiki di seluruh fleet dan tidak menemukan bukti bahwa penyerang lain memanfaatkannya.

Masalah ini dilaporkan pada 4 September 2026 oleh Oren Yomtov, peneliti keamanan dari Accomplish, melalui program bug bounty Cloudflare. Dalam tulisan teknis yang diterbitkan Cloudflare pada 24 September, perusahaan menjelaskan bahwa akar masalahnya bukan container escape klasik. Celah berada di lapisan penyimpanan yang dipakai untuk memberi setiap container sebuah root disk yang dapat ditulis.

Cloudflare Containers berjalan pada infrastruktur multi-tenant. Workload pelanggan ditempatkan otomatis ke server yang memenuhi syarat, sementara pelanggan tidak memilih host fisik secara langsung. Setiap container berjalan di dalam virtual machine berbasis Firecracker dan menerima disk virtual melalui perangkat `/dev/vdc`.

Disk tersebut menggunakan Linux device-mapper thin provisioning. Sistem ini tidak langsung mencadangkan seluruh kapasitas fisik. Blok penyimpanan dialokasikan ketika disk virtual menulis ke wilayah yang sebelumnya belum dipetakan. Pada konfigurasi yang terdampak, pool penyimpanan memakai ukuran thin block 64 KiB dan opsi `skip_block_zeroing`.

Opsi itu membuat blok baru tidak selalu dibersihkan sebelum diberikan kepada container berikutnya. Jika sebuah blok fisik sebelumnya dipakai tenant lain lalu dialokasikan ulang, penulisan penuh akan mengganti seluruh isinya. Namun, penulisan yang lebih kecil hanya mengganti bagian yang ditulis. Sisa byte pada blok tersebut berpotensi masih berisi data dari pemilik sebelumnya.

Proof of concept dari peneliti memanfaatkan perbedaan ukuran itu. Mereka menulis blok 4 KiB pada wilayah tertentu yang sejajar dengan thin block 64 KiB, lalu membaca kembali blok yang sama dari perangkat mentah. Empat kilobyte pertama berisi data baru, tetapi 60 KiB sisanya dapat mempertahankan isi lama. Teknik tersebut tidak memberi penyerang kendali untuk memilih korban, workload, host, atau file tertentu. Data lama juga tidak selalu tersedia. Meski begitu, batas isolasi antar-tenant tetap bisa ditembus dalam kondisi tertentu.

Cloudflare mengatakan pengujian peneliti menemukan material residual pada 18 dari 24 penempatan dan 20 dari 22 node yang diuji di empat benua. Jenis data yang teridentifikasi mencakup struktur direktori, halaman database, dan database SQLite yang secara struktural lengkap. Peneliti memakai checksum direktori ext4 untuk membedakan blok milik filesystem pengujian dari blok yang berasal dari filesystem lain. Materi yang dikirim ke Cloudflare tidak berisi nama file, kredensial, hostname, alamat, atau nilai isi data milik pihak ketiga. Accomplish juga menyatakan data hasil pengujian telah dihapus secara aman.

Cloudflare menerapkan mitigasi pertama dengan menghapus `skip_block_zeroing` dari konfigurasi pool dm-thin. Langkah ini mengembalikan perilaku bawaan dm-thin: alokasi baru dibersihkan sebelum dapat diakses oleh container. Peneliti kemudian mengonfirmasi bahwa proof of concept tidak lagi bekerja setelah perubahan itu diterapkan.

Perbaikan tersebut belum cukup untuk membersihkan blok yang sudah terhubung ke disk yang sedang berjalan atau snapshot image yang masih tersimpan di cache host. Karena itu, Cloudflare juga menghentikan seluruh disk container yang berjalan, menghapus snapshot image lama, menguras host pada jam operasional rendah, lalu membuat ulang disk dan cache dengan alokasi yang sudah dibersihkan. Perusahaan menyatakan proses pembersihan seluruh fleet selesai pada 19 September 2026.

Cloudflare juga meninjau telemetri disk historis untuk mencari pola yang mirip dengan proof of concept, yaitu penulisan kecil pada wilayah yang belum dipetakan diikuti pembacaan yang mengambil data jauh lebih besar. Dari aktivitas yang cocok, perusahaan hanya mengaitkannya dengan peneliti dan engineer Cloudflare saat validasi terotorisasi. Mereka tidak menemukan bukti jalur serangan tersebut dipakai aktor berbahaya lain.

Bagi pelanggan Cloudflare Containers dan Sandboxes, perusahaan menyatakan tidak ada konfigurasi tambahan yang perlu diubah. Pernyataan itu tidak menghapus arti teknis insiden ini: pada sistem multi-tenant, pengaturan default di lapisan storage bisa sama pentingnya dengan boundary virtual machine dan container. Membersihkan blok sebelum reuse terdengar sederhana, tetapi cache, snapshot, dan disk yang sudah berjalan membuat remediasi harus mencakup seluruh jejak penyimpanan lama.

Kasus ini juga memperlihatkan mengapa pengungkapan teknis setelah perbaikan tetap berguna. Cloudflare tidak hanya menyebut bahwa celah telah ditutup, tetapi menjelaskan mekanisme alokasi, batas eksploitasi, tahapan cleanup, dan cara mereka mencari tanda penyalahgunaan. Untuk operator infrastruktur, detail seperti itu membantu membedakan antara klaim “sudah dipatch” dan remediasi yang benar-benar menyentuh data lama, cache, serta telemetry.

Sumber utama: - Cloudflare, “How Cloudflare addressed a cross-tenant data exposure vulnerability in Containers” (24 September 2026): https://blog.cloudflare.com/containers-cross-tenant-vulnerability/

Sumber tambahan: - The Hacker News, “Cloudflare Fixes Flaw That Let One Container Read Another Customer's Leftover Disk Data” (25 September 2026): https://thehackernews.com/2026/09/cloudflare-fixes-flaw-that-let-one.html