Cloudflare устранила доступ к остаточным данным между контейнерами

Cloudflare устранила ошибку в сервисе Cloudflare Containers, из-за которой платный клиент мог прочитать остаточные данные, оставшиеся на диске после работы контейнера другого клиента. Проблема затронула также Cloudflare Sandboxes, построенный на Containers; исследователи в производственных тестах обнаруживали следы данных в 18 из 24 попыток на 20 из 22 физических машинах в четырёх регионах.

Уязвимость 4 сентября сообщил Орен Йомтов из компании Accomplish через программу bug bounty. Cloudflare завершила очистку инфраструктуры 19 сентября и раскрыла информацию через пять дней. По заявлению компании, действий со стороны клиентов не требуется.

Как возникала утечка

Containers запускает программы клиентов в контейнерах на общих серверах, а размещение на конкретном сервере выбирает сама Cloudflare. Для дисков использовался механизм Linux thin provisioning: хранилище выделяется блоками по 64 КБ. После удаления контейнера его блоки возвращались в общий пул, доступный аккаунтам разных клиентов.

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

Исследователи записывали 4 КБ в свободную область, а затем считывали весь блок на уровне необработанного диска. Таким способом они получали до 60 КБ старого содержимого. Cloudflare сообщила, что среди найденного были структуры каталогов, страницы баз данных и структурно завершённые базы SQLite. В отчёте Accomplish также упомянуты профили Chromium, файлы .env и файлы с учётными данными.

Что исправила Cloudflare

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

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

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

Что это означает для компаний

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