Cloudflare устранила уязвимость межклиентской изоляции в сервисах Cloudflare Containers и Cloudflare Sandboxes после того, как исследователи из команды Accomplish доказали, что пользователь с аккаунтом Workers Paid мог восстановить остатки данных из блоков хранения, ранее использовавшихся контейнерами других клиентов на том же хосте. Исследователь Oren Yomtov сообщил компании о проблеме 4 сентября 2026 года через программу вознаграждений за обнаружение уязвимостей, а Cloudflare заявила, что не обнаружила признаков компрометации клиентских данных.
Как возникла проблема?
Containers использует технологию Linux device mapper thin provisioning для предоставления доступного для записи корневого диска внутри виртуальной машины, работающей через Firecracker. В затронутых пулах хранения использовались блоки размером 64 килобайта с включённой опцией skip_block_zeroing, поэтому повторно выделяемые блоки не обнулялись перед предоставлением новому контейнеру.
Когда в части нового блока записывалось только 4 килобайта, оставшиеся 60 килобайт могли сохранять данные предыдущего владельца. Последующее чтение с необработанного устройства /dev/vdc могло раскрыть эти байты, несмотря на то что новый контейнер никогда их не записывал.
Что показало тестирование?
Эксплуатация не позволяла выбрать конкретного клиента, контейнер или хост, а появление остатков данных не было гарантировано. Тем не менее исследователи сообщили, что обнаружили остаточные материалы в 18 из 24 проверенных мест и на 20 из 22 основных узлов на четырёх континентах. Среди обнаруженных типов данных были структуры каталогов, страницы баз данных и структурно完整ные базы SQLite.
Исследователи использовали контрольные суммы и метаданные файловой системы ext4, чтобы отличать блоки своей тестовой системы от блоков, поступавших из других файловых систем. Согласно опубликованным результатам, было идентифицировано 2 700 узлов каталогов, принадлежавших другим системам, тогда как ни один из 5 614 тестовых блоков каталогов не был отнесён к системе исследователей. Cloudflare заявляет, что переданные ей материалы не содержали имён файлов, идентификаторов, учётных данных или восстановленного содержимого, а исследователи безопасно удалили имевшиеся у них данные.
Как Cloudflare устранила проблему?
Компания удалила опцию skip_block_zeroing из настроек пулов dm-thin, благодаря чему новые блоки вернулись к поведению по умолчанию и обнулялись перед предоставлением. Исследователи независимо подтвердили, что после этого изменения проверка концепции больше не работала.
Однако обнуления новых выделений было недостаточно, поскольку некоторые блоки всё ещё были связаны с существующими дисками контейнеров или временными снимками слоёв образов OCI. Поэтому Cloudflare остановила старые диски контейнеров, удалила кэшированные до исправления снимки, очистила хосты, перезапустила виртуальные машины и очистила кэш образов. Эта очистка завершилась 19 сентября 2026 года, а развёртывание основного исправления было завершено 7 сентября.
Почему эта новость важна?
Важность инцидента заключается в том, что он показывает: изоляция клиентов в облачной инфраструктуре зависит не только от виртуальных машин; особенности повторного использования хранилища и поведения тонкого выделения могут открыть канал утечки неактивных данных. В то же время практические ограничения были очевидны: тестирование не позволяло направленно атаковать конкретную жертву или получить доступ к фактически подключённому диску, а изменение данных другого клиента или влияние на доступность его рабочих нагрузок доказано не было.
Cloudflare проверила исторические журналы измерений ввода-вывода дисков в поисках характерной закономерности, сочетающей записи по 4 килобайта и более крупные чтения. Компания отнесла активность, соответствующую этой закономерности, к исследователям и своим инженерам во время санкционированной проверки и не обнаружила дополнительной активности, указывающей на эксплуатацию атаки кем-либо ещё. Согласно компании, клиентам Cloudflare не требуется предпринимать никаких действий в связи с исправлением.