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

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

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

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

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

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

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

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

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

skip_block_zeroing

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

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

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

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

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

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

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

Создание контейнера с использованием платного аккаунта Workers.

Открытие доступного для записи корневого диска по адресу /dev/vdc.

Чтение диска и запись базовых показателей (baseline).

Запись одного блока размером 4 КиБ в каждую выбранную область размером 64 КиБ, соответствующую свободному пространству ext4.

Повторное чтение полученных блоков.

Изучение только тех частей, которые не были перезаписаны новым контейнером.

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

Как проверялась уязвимость

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

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

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

Все 5 614 проверяемых блоков каталогов.

Ноль из этих блоков были отнесены к файловой системе исследователей.

2 700 различных посторонних инодов каталогов, выявленных с помощью анализа контрольных сумм.

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

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

Воздействие

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

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

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

Как мы смягчили последствия уязвимости

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

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

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

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

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

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

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

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

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

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

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

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

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

Хронология

4 сентября, 15:26 UTC: Орен Йомтов из Accomplish сообщил о проблеме через 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 завершила очистку всех кэшированных снимков, созданных до внедрения средств защиты, во всем затронутом парке машин.