4 сентября 2026 года Орен Йомтов (Oren Yomtov), специалист по безопасности из Accomplish, ответственно сообщил об уязвимости, затрагивающей Cloudflare Containers и Cloudflare Sandboxes (которые созданы на базе Containers), через программу выплаты вознаграждений за найденные уязвимости Cloudflare. Компания Cloudflare полностью устранила эту уязвимость, и у нас нет никаких данных, подтверждающих факт компрометации пользовательской информации.

Эта публикация была подготовлена в сотрудничестве с Ореном Йомтовым и исследовательской группой безопасности Accomplish, чей подробный отчет и контролируемое тестирование помогли нам подтвердить проблему и оперативно отреагировать.

Cloudflare Containers запускают рабочие нагрузки на мультиарендной инфраструктуре и автоматически назначают их на подходящие серверы; клиенты не могут выбирать базовый хост. Исследователи продемонстрировали, что клиент с аккаунтом Workers Paid мог восстановить остаточные дисковые блоки, ранее использовавшиеся Containers на том же хосте. Данный метод не позволял нацелиться на конкретного клиента, рабочую нагрузку, хост или данные, а наличие остаточных данных не гарантировалось.

Cloudflare применила исправление для всего парка Containers, при этом изменения конфигурации со стороны клиентов не потребовались. На основе доступной нам исторической телеметрии дискового ввода-вывода мы не обнаружили никаких признаков злонамеренной эксплуатации. Активность, которую мы смогли соотнести с описанным методом, исходила от исследователей и инженеров Cloudflare, проводивших авторизованную проверку.

Ниже мы объясняем лежащее в основе поведение системы хранения, ее потенциальное влияние, проведенное нами расследование и предпринятые в ответ действия.

Как работает выделение хранилища для контейнеров

Cloudflare Containers используют механизм тонкого провизионирования dm-thin в Linux (thin provisioning) для предоставления каждому контейнеру записываемого корневого диска. Каждый контейнер находится внутри выделенной виртуальной виртуальной машины под управлением монитора виртуальных машин Firecracker. Firecracker представляет этот диск для виртуальной машины как /dev/vdc.

Тонкое провизионирование выделяет физическое хранилище только тогда, когда на виртуальный диск выполняется запись в ранее не задействованную область. Затронутые пулы хранения использовали размер тонкого блока 64 КиБ. Когда тонкий том, поддерживающий корневой диск контейнера, удалялся, его физические блоки возвращались в пул, который обслуживал рабочие нагрузки, принадлежащие нескольким клиентским аккаунтам.

Затронутая конфигурация пула включала следующую опцию:

skip_block_zeroing

При такой конфигурации dm-thin пропускает обнуление вновь выделенных блоков перед тем, как сделать их доступными. Следовательно, когда ранее использовавшийся блок размером 64 КиБ переназначался, запись полного блока заменяла его предыдущее содержимое, но меньшая запись изменяла только записанную часть. Оставшаяся часть могла содержать данные предыдущего владельца блока.

Как работал эксплойт

Чтение нераспределенной области нового тонкого диска не раскрывало остаточные данные. Для нераспределенной области тонкого устройства dm-thin возвращал нули без выделения физического блока.

Концептуальное доказательство (proof of concept) определило области, выровненные по границе 64 КиБ, которые соответствуют свободному пространству в гостевой файловой системе ext4, и записало по одному выровненному блоку размером 4 КиБ в каждую область.

Когда такая запись достигала нераспределенного тонкого блока, dm-thin выделял физический блок размером 64 КиБ из общего пула. Запись размером 4 КиБ заменяла только эту часть блока, и поскольку обнуление блоков было отключено, оставшиеся 60 КиБ могли сохранять данные предыдущего контейнера.

В результате последующее чтение необработанного устройства (raw-device read) позволяло увидеть байты, которые новый контейнер никогда не записывал.

Концептуальное доказательство выполняло следующие шаги:

Создание контейнера с использованием аккаунта Workers Paid.
Открытие записываемого корневого диска по адресу /dev/vdc.
Чтение диска и запись базовых данных (baseline).
Запись одного блока размером 4 КиБ в каждую выбранную область размером 64 КиБ, соответствующую свободному пространству ext4.
Повторное чтение полученных блоков.
Изучение только тех частей, которые не были перезаписаны новым контейнером.

Предоставленные материалы содержали счетчики, смещения блоков, размеры, результаты контрольных сумм и усеченные префиксы хешей. Хотя исследователи восстановили необработанные блоки для подтверждения проблемы, материалы, переданные в Cloudflare, не содержали имен файлов третьих лиц, идентификаторов, учетных данных, имен хостов, адресов или восстановленных значений контента. Как описано ниже, исследователи также подтвердили, что они безопасно удалили восстановленные данные.

Как была подтверждена уязвимость

Исследователи использовали контрольные суммы блоков каталогов ext4, чтобы отличать блоки, принадлежащие их собственной тестовой файловой системе, созданной для концептуального доказательства, от блоков, происходящих из других файловых систем.

Когда в ext4 используется функция metadata_csum, контрольные суммы блоков каталога включают значения, связанные с файловой системой и инодой.

В ходе шести производственных размещений исследователи зафиксировали:

Всего 5 614 тестируемых блоков каталогов.
Ноль из этих блоков относился к файловой системе исследователей.
2 700 уникальных чужеродных инод каталогов, идентифицированных посредством анализа контрольных сумм.

Для проверки метода исследователи протестировали его на блоках, которые они намеренно создали и удалили в контролируемой тестовой файловой системе, использовавшейся для концептуального доказательства. Метод корректно отнес все 162 блока к этой файловой системе.

В конечном итоге исследователи обнаружили остаточные материалы на 18 из 24 размещений и 20 из 22 базовых узлов на четырех континентах. Типы восстановленных блоков включали структуры каталогов, страницы баз данных и структурно полные базы данных SQLite. Исследователи сообщили, что использовали скрипты, выводящие только общие счетчики и проверки формата, но не восстановленное содержимое файлов. Материалы, отправленные в Cloudflare, не содержали восстановленных значений контента или идентификаторов третьих лиц. Впоследствии исследователи подтвердили, что находящиеся под их контролем восстановленные данные остались конфиденциальными и были безопасно удалены после отправки отчета в соответствии с политикой раскрытия информации Cloudflare на платформе HackerOne.

Влияние

Уязвимость потенциально могла позволить клиенту с аккаунтом Workers Paid восстановить остаточные данные из блоков хранения, ранее использовавшихся Containers других клиентов на том же базовом хосте.

Успешная эксплуатация нарушила бы границу изоляции арендаторов и могла бы раскрыть метаданные файловой системы, структуры каталогов, страницы баз данных и данные приложений.

Тем не менее, злоумышленник не мог выбрать конкретную жертву или получить доступ к активно подключенному диску. Уязвимость зависела от размещения рабочих нагрузок Cloudflare и от того, какие ранее освобожденные блоки переназначал dm-thin. Более того, исследователи не продемонстрировали возможность модификации активных данных другого клиента или влияния на доступность рабочих нагрузок.

Как мы устранили уязвимость

Нашей первой мерой по устранению было удаление skip_block_zeroing из конфигурации пула dm-thin для всего парка. Это восстановило стандартное поведение dm-thin, заключающееся в очистке вновь выделенных блоков перед предоставлением их контейнеру. Это остановило описанный метод, при котором небольшая запись инициировала выделение, а большее чтение восстанавливало остаточные данные из оставшейся части блока. Исследователи независимо подтвердили, что их концептуальное доказательство перестало работать после этого изменения.

Обнуление новых выделений памяти не очищало блоки, уже отображенные на существующие тонкие устройства. Эти отображения существовали на дисках запущенных контейнеров и в кеше подготовленных снимков dm-thin для слоев образов OCI на каждом хосте. Новый контейнер мог унаследовать отображения из кешированного слоя без повторного выделения этих блоков, что позволяло остаточным байтам в неиспользуемых областях, включая свободное пространство ext4, оставаться доступными для чтения посредством прямых чтений /dev/vdc.

Поэтому мы также вывели из эксплуатации все диски запущенных контейнеров и удалили кешированные снимки образов, созданные до внедрения средств защиты. Мы разгрузили хосты в часы наименьшей нагрузки, перезапустили виртуальные машины на каждом хосте и очистили кеш образов каждого хоста, чтобы диски и кешированные слои были воссозданы с использованием обнуленных выделений. Мы завершили эту очистку во всем парке контейнеров.

Нет никаких признаков эксплуатации

В рамках нашего реагирования мы провели расследование, чтобы выяснить, проявляли ли другие рабочие нагрузки активность, соответствующую описанной технике эксплуатации. Мы изучили сохраненную историческую телеметрию дискового ввода-вывода нашей контейнерной инфраструктуры, используя концептуальный пример (PoC) исследователей и нашу внутреннюю реализацию для привязки к эталонной активности.

Концептуальный пример демонстрировал характерную взаимосвязь между операциями записи и чтения. Когда запись объемом 4 КиБ достигала ранее не отображенной области, это могло инициировать выделение повторно используемого блока хранения объемом 64 КиБ. При отключенном обнулении оставшиеся 60 КиБ могли сохранять данные из предыдущего контейнера. Следовательно, последующие операции чтения позволяли восстановить значительно больше данных, чем записал новый контейнер.

Используя эти характеристики, мы разработали сигнатуры обнаружения и применили их к доступной нам исторической телеметрии. Мы выявили активность, обусловленную действиями исследователей и инженеров Cloudflare, проводивших авторизованную проверку, и не обнаружили никакой другой активности, соответствующей описанной технике.

Мы не обнаружили никаких признаков того, что этот конкретный вектор атаки эксплуатировался кем-либо еще.

Клиенты Cloudflare защищены

Как мы отмечали выше, Cloudflare устранила эту уязвимость, и исправление не требует каких-либо дальнейших действий со стороны клиентов Cloudflare. Кроме того, мы не обнаружили никаких свидетельств того, что какие-либо злоумышленники злоупотребляли этой уязвимостью.

Быстрые действия и прозрачность

Мы благодарим Орена Йомтова (Oren Yomtov) и исследовательскую группу по безопасности Accomplish за их тщательное исследование, ответственное раскрытие информации и совместную работу над этим материалом. Мы призываем сообщество Cloudflare сообщать о любых выявленных уязвимостях, чтобы помогать нам постоянно улучшать уровень безопасности наших продуктов и платформы.

Мы также понимаем, что доверие, которое вы нам оказываете, имеет первостепенное значение для успешной работы вашей инфраструктуры на Cloudflare. Мы очень серьезно относимся к таким уязвимостям и продолжим делать все от нас зависящее для минимизации их последствий. Мы глубоко ценим вашу неизменную поддержку и доверие к нашей платформе и по-прежнему привержены не только обеспечению безопасности во всем, что мы делаем, но и оперативному и прозрачному реагированию при возникновении любых проблем.

Хронология

4 сентября, 15:26 UTC: Орен Йомтов из сообщил о проблеме через HackerOne.
4 сентября, 18:45 UTC: Cloudflare открыла инцидент безопасности и подтвердила конфигурацию рабочей среды, вызвавшую эту уязвимость.
4 сентября, 21:27 UTC: Cloudflare объединила исправление среды выполнения и тест на ее повторное использование.
4 сентября, 22:03 UTC: Cloudflare объединила изменения для новых и активных пулов.
4 сентября, 23:15 UTC: Cloudflare начала развертывание изменений.
7 сентября, 06:13 UTC: Cloudflare завершила развертывание изменений и приступила к очистке данных старого пула.
14 сентября, 10:50 UTC: Исследователи сообщили, что их концептуальный пример перестал работать.
14 сентября, 12:52 UTC: Cloudflare выплатила исследователю вознаграждение.
19 сентября, 15:03 UTC: Cloudflare завершила очистку всех кешированных снимков, созданных до внедрения средств защиты, во всем затронутом парке машин.