Cloudflare закрыла уязвимость, позволявшую читать остатки данных чужих контейнеров
Автор: Марта Баринова Cloudflare устранила уязвимость в сервисах Containers и Sandboxes, из-за которой клиент с платным аккаунтом Workers мог получить остатки данных из контейнеров других клиентов. Для этого контейнеры должны были оказаться на одном сервере и получить блоки из общего хранилища. Компания завершила исправление и не обнаружила признаков злонамеренного использования уязвимости.
О проблеме 4 сентября 2026 года сообщил исследователь Орен Йомтов из Accomplish через программу вознаграждений Cloudflare за найденные ошибки. Уязвимость затрагивала Containers и построенный на его основе сервис Sandboxes. Исследователи проверили её на действующей инфраструктуре: остаточные данные обнаружились в 18 из 24 размещений контейнеров и на 20 из 22 серверов, участвовавших в проверке.
Полученные блоки содержали структуры каталогов, страницы баз данных и структурно полные базы SQLite. При этом способ не позволял выбрать конкретного клиента, его контейнер, сервер или данные. Доступность остатков зависела от того, куда Cloudflare размещала нагрузку и какие освобождённые блоки хранилище выдавало повторно. Прочитать диск, который в тот момент использовал другой контейнер, таким способом было нельзя.
Уязвимость Cloudflare: как возникла проблема
Контейнеры Cloudflare работают в отдельных виртуальных машинах, но получают место для записи из пула хранения, обслуживающего разные клиентские аккаунты. Когда диск контейнера удаляли, его физические блоки возвращались в этот пул. В затронутой конфигурации новые владельцы могли получить ранее использованный блок без предварительной очистки. Размер такого блока составлял 64 КиБ.
Исследователи записывали 4 КиБ в выбранную свободную область диска нового контейнера. Если хранилище выделяло для записи повторно использованный блок размером 64 КиБ, запись заменяла только его часть. В оставшихся 60 КиБ могли сохраниться данные прежнего контейнера, которые затем удавалось прочитать напрямую с дискового устройства. Простое чтение ещё не выделенной области этого эффекта не давало: до записи она возвращала нули.
Исследователи использовали контрольные суммы каталогов ext4, чтобы отличать блоки своего тестового контейнера от блоков других файловых систем. В материалах, переданных Cloudflare, не было извлечённого содержимого файлов и идентификаторов третьих лиц: там приводились результаты проверок и сводные числа. По подтверждению исследователей, полученные при тестировании данные хранились конфиденциально, а после передачи сообщения об уязвимости были безопасно удалены. Возможность изменить действующие данные другого клиента или нарушить работу его контейнера они не продемонстрировали.
Как Cloudflare исправила проблему
Сначала Cloudflare отключила настройку, из-за которой повторно выделяемые блоки не очищались. После этого исследователи подтвердили, что их способ извлечения данных перестал работать. Но одной смены настройки было недостаточно: она не очищала блоки, уже привязанные к работающим дискам контейнеров и сохранённым снимкам образов.
Компания также вывела из использования прежние диски контейнеров и удалила кэшированные снимки, созданные до исправления. Для этого она перезапустила виртуальные машины на серверах и очистила кэш образов, чтобы диски создавались заново с очищенными блоками. Развёртывание изменения завершилось 7 сентября, а очистка ранее созданных снимков по всей затронутой инфраструктуре закончилась 19 сентября. Клиентам менять настройки не требуется.
Cloudflare проверила доступные исторические данные о дисковых операциях, ориентируясь на характерную последовательность записей и чтений при таком способе извлечения информации. Компания нашла активность исследователей и собственных инженеров, которые проверяли уязвимость с разрешения, но не обнаружила других совпадающих случаев. Доказательств того, что клиентские данные были скомпрометированы, у Cloudflare нет.
