В Cloudflare Containers обнаружили уязвимость, позволявшую одному платному клиенту прочитать данные, оставшиеся на диске после удаления контейнера другого клиента. Речь шла о дисковом пространстве, которое ранее использовала чужая рабочая нагрузка, а затем вернула системе. Активные процессы и работающие контейнеры затронуты не были. Получить данные конкретной выбранной жертвы злоумышленник тоже не мог: содержимое зависело от того, какие блоки диска система выдавала повторно.
Проблема касалась Cloudflare Containers, где программы клиентов запускаются внутри контейнеров на серверах, общих для множества аккаунтов. Сервер для конкретного контейнера выбирает Cloudflare, а не сам клиент. Уязвимым оказался и Cloudflare Sandboxes, работающий поверх Containers и предназначенный для безопасного запуска недоверенного кода, включая код, созданный ИИ-агентами. Исследователи отдельно сообщили, что та же конфигурация дисков затрагивала Cloudflare Browser Run. В публичном раскрытии Cloudflare назвала Containers и Sandboxes, но Browser Run не упомянула.
Уязвимость 4 сентября обнаружил Орен Йомтов (Oren Yomtov), сотрудник компании Accomplish. Он сообщил о ней через bug bounty program Cloudflare. Исследователи проверили проблему в производственной среде: остаточные данные удалось найти в 18 из 24 попыток на серверах, которые выбирала сама Cloudflare. При проверке базовых физических машин результат оказался ещё шире: данные обнаружились на 20 из 22 машин, расположенных на четырёх континентах.
Причина заключалась в использовании Linux-механизма thin provisioning. Для каждого контейнера создавался виртуальный диск, а хранилище распределялось блоками по 64 килобайта. После удаления контейнера блоки возвращались в общий пул, которым пользовались аккаунты разных клиентов. При этом система была настроена пропускать очистку блоков перед их повторной выдачей. Очистка обычно включена по умолчанию, но в данном случае этот шаг оказался отключён.
Механизм извлечения был простым. Исследователи записывали в свободное место блока лишь 4 килобайта, а затем читали весь блок объёмом 64 килобайта на уровне необработанного диска. Записанная часть содержала данные нового контейнера, тогда как оставшиеся 60 килобайт сохраняли байты от прежнего контейнера. Так удавалось восстанавливать фрагменты информации, принадлежавшей другому клиенту и считавшейся удалённой.
В найденных блоках были каталоги, страницы баз данных и структурно целые базы SQLite. В отчёте исследователей также перечислены списки каталогов, профили браузера Chromium, файлы.env, файлы с учётными данными и другие клиентские данные. Скрипты анализа выводили только количество найденных объектов и результаты проверки форматов, не показывая содержимое файлов. Отправленные Cloudflare материалы, по словам исследователей, не содержали имён третьих лиц, идентификаторов, паролей или восстановленного контента. Исследователи заявили, что хранили данные конфиденциально и безопасно удалили их после передачи отчёта.
Проверка не показала, что через эту уязвимость можно было изменить активные данные другого клиента или вывести его рабочую нагрузку из строя. Cloudflare сообщила, что обнаружила признаки только авторизованных действий исследователей и собственных инженеров. Для проверки компания создала сигнатуры по proof of concept исследователей и по собственной копии атаки, а затем сопоставила их с сохранившимися журналами дисковой активности. Следовательно, заявление об отсутствии других атак относится лишь к тем записям, которые Cloudflare сохранила. Компания не раскрыла, за какой период велись журналы и когда именно появилась небезопасная настройка, поэтому общий срок возможного воздействия остаётся неизвестным.
Исправление проводилось в два этапа. Сначала Cloudflare снова включила очистку блоков перед выдачей новым контейнерам. 14 сентября исследователи подтвердили, что их proof of concept после этого перестал работать. Но включение очистки не убирало блоки, которые уже были подключены к дискам работающих контейнеров или находились в кэше подготовленных слоёв образов на серверах. Новый контейнер всё ещё мог получить доступ к части таких заранее размещённых блоков.
Затем Cloudflare вывела из эксплуатации все действующие диски контейнеров, очистила кэши со слоями образов, осушила и перезапустила серверы. Работы проводились в часы низкой нагрузки и завершились 19 сентября. Публично об уязвимости Cloudflare и исследователи сообщили в четверг, через пять дней после окончания очистки. Клиентам, согласно уведомлению Cloudflare, предпринимать какие-либо действия не требуется.
Исследователи назвали этот случай своим шестым опубликованным выходом из изолированной среды выполнения кода с июля. До Cloudflare они описывали проблемы в Anthropic Claude Cowork, Anthropic Claude Code, командном инструменте Cursor, Docker и OpenAI Codex. Случай с Cloudflare они также отнесли к sandbox escape: код из одного клиентского окружения получал доступ к остаткам данных, принадлежавших другому окружению. Разница здесь в том, что речь шла о ранее освобождённых блоках диска, а не о содержимом активной рабочей нагрузки.
Изображение носит иллюстративный характер
Проблема касалась Cloudflare Containers, где программы клиентов запускаются внутри контейнеров на серверах, общих для множества аккаунтов. Сервер для конкретного контейнера выбирает Cloudflare, а не сам клиент. Уязвимым оказался и Cloudflare Sandboxes, работающий поверх Containers и предназначенный для безопасного запуска недоверенного кода, включая код, созданный ИИ-агентами. Исследователи отдельно сообщили, что та же конфигурация дисков затрагивала Cloudflare Browser Run. В публичном раскрытии Cloudflare назвала Containers и Sandboxes, но Browser Run не упомянула.
Уязвимость 4 сентября обнаружил Орен Йомтов (Oren Yomtov), сотрудник компании Accomplish. Он сообщил о ней через bug bounty program Cloudflare. Исследователи проверили проблему в производственной среде: остаточные данные удалось найти в 18 из 24 попыток на серверах, которые выбирала сама Cloudflare. При проверке базовых физических машин результат оказался ещё шире: данные обнаружились на 20 из 22 машин, расположенных на четырёх континентах.
Причина заключалась в использовании Linux-механизма thin provisioning. Для каждого контейнера создавался виртуальный диск, а хранилище распределялось блоками по 64 килобайта. После удаления контейнера блоки возвращались в общий пул, которым пользовались аккаунты разных клиентов. При этом система была настроена пропускать очистку блоков перед их повторной выдачей. Очистка обычно включена по умолчанию, но в данном случае этот шаг оказался отключён.
Механизм извлечения был простым. Исследователи записывали в свободное место блока лишь 4 килобайта, а затем читали весь блок объёмом 64 килобайта на уровне необработанного диска. Записанная часть содержала данные нового контейнера, тогда как оставшиеся 60 килобайт сохраняли байты от прежнего контейнера. Так удавалось восстанавливать фрагменты информации, принадлежавшей другому клиенту и считавшейся удалённой.
В найденных блоках были каталоги, страницы баз данных и структурно целые базы SQLite. В отчёте исследователей также перечислены списки каталогов, профили браузера Chromium, файлы.env, файлы с учётными данными и другие клиентские данные. Скрипты анализа выводили только количество найденных объектов и результаты проверки форматов, не показывая содержимое файлов. Отправленные Cloudflare материалы, по словам исследователей, не содержали имён третьих лиц, идентификаторов, паролей или восстановленного контента. Исследователи заявили, что хранили данные конфиденциально и безопасно удалили их после передачи отчёта.
Проверка не показала, что через эту уязвимость можно было изменить активные данные другого клиента или вывести его рабочую нагрузку из строя. Cloudflare сообщила, что обнаружила признаки только авторизованных действий исследователей и собственных инженеров. Для проверки компания создала сигнатуры по proof of concept исследователей и по собственной копии атаки, а затем сопоставила их с сохранившимися журналами дисковой активности. Следовательно, заявление об отсутствии других атак относится лишь к тем записям, которые Cloudflare сохранила. Компания не раскрыла, за какой период велись журналы и когда именно появилась небезопасная настройка, поэтому общий срок возможного воздействия остаётся неизвестным.
Исправление проводилось в два этапа. Сначала Cloudflare снова включила очистку блоков перед выдачей новым контейнерам. 14 сентября исследователи подтвердили, что их proof of concept после этого перестал работать. Но включение очистки не убирало блоки, которые уже были подключены к дискам работающих контейнеров или находились в кэше подготовленных слоёв образов на серверах. Новый контейнер всё ещё мог получить доступ к части таких заранее размещённых блоков.
Затем Cloudflare вывела из эксплуатации все действующие диски контейнеров, очистила кэши со слоями образов, осушила и перезапустила серверы. Работы проводились в часы низкой нагрузки и завершились 19 сентября. Публично об уязвимости Cloudflare и исследователи сообщили в четверг, через пять дней после окончания очистки. Клиентам, согласно уведомлению Cloudflare, предпринимать какие-либо действия не требуется.
Исследователи назвали этот случай своим шестым опубликованным выходом из изолированной среды выполнения кода с июля. До Cloudflare они описывали проблемы в Anthropic Claude Cowork, Anthropic Claude Code, командном инструменте Cursor, Docker и OpenAI Codex. Случай с Cloudflare они также отнесли к sandbox escape: код из одного клиентского окружения получал доступ к остаткам данных, принадлежавших другому окружению. Разница здесь в том, что речь шла о ранее освобождённых блоках диска, а не о содержимом активной рабочей нагрузки.
