Как компания Cloudflare устранила уязвимость утечки данных между арендаторами в сервисе Containers24.09.2026 18:00

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

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

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

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

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

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

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

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

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

skip_block_zeroing

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

Как работала эксплуатация

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Воздействие 

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

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

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

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

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

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

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

Свидетельства эксплуатации отсутствуют

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

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

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

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

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

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

Быстрое движение в условиях прозрачности 

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

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

Хронология

• 4 сентября, 15:26 UTC: Орен Йомтов из Accomplish сообщил о проблеме через HackerOne.
• 4 сентября, 18:45 UTC: Cloudflare зарегистрировала инцидент безопасности и подтвердила конфигурацию рабочей среды, вызвавшую сбой.
• 4 сентября, 21:27 UTC: Cloudflare объединила исправление среды выполнения (runtime fix) и тест его повторного использования.
• 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 завершила очистку всех кэшированных снимков, созданных до применения исправления, по всему затронутому парку серверов.

© Cloudflare Blog