Уязвимость Cloudflare Containers позволяла платным пользователям Workers читать остатки данных из контейнеров других клиентов, если те раньше работали на том же физическом хосте. Для русскоязычных команд, которые выносят фоновые задачи, песочницы и backend-сервисы в облачные рантаймы, это неприятное напоминание: мультиарендность держится не только на красивой схеме из презентации, но и на скучной операции очистки блоков диска.
Проблему обнаружил исследователь Oren Yomtov из компании Accomplish и отправил отчет через HackerOne 4 сентября 2026 года, сообщает BleepingComputer. Cloudflare исправила баг в Containers и Sandboxes, завершив меры по устранению риска к 19 сентября 2026 года. Клиентам ничего вручную делать не нужно: исправления применены на стороне инфраструктуры.
Cloudflare Containers — сервис для пользователей Workers Paid, который позволяет запускать контейнеризированные приложения рядом с Cloudflare Workers. Его используют для backend-сервисов, фоновой обработки, задач выполнения кода и похожих сценариев, где разработчикам хочется получить контейнер, но не хочется собирать вокруг него полноценный кластер с собственной эксплуатацией. Именно здесь и проявилась проблема: контейнеры разных клиентов могли использовать физические блоки из общего пула хранения.
Ошибка была не в том, что один клиент мог подключиться к активному диску другого клиента. Такого сценария исследователи не показали. Слабое место оказалось тоньше и, честно говоря, противнее: когда thin volume, на котором лежал root-диск контейнера, удалялся, его физические блоки возвращались в общий пул. Из-за настройки, отключавшей обнуление повторно используемых блоков размером 64 КиБ, новый контейнер мог получить кусок диска с остатками предыдущего содержимого.
Механика выглядела почти учебниково. Исследователи записывали всего 4 КиБ в неиспользуемую область диска нового контейнера. Это приводило к выделению физического блока на 64 КиБ. Но перезаписывались только эти 4 КиБ, а оставшиеся 60 КиБ могли сохранять данные от предыдущего пользователя. В найденных остатках встречались структуры директорий, страницы SQLite, целые SQLite-базы, профили Chromium, файлы .env и credential-файлы. То есть не просто мусор, а ровно тот класс артефактов, который в реальных проектах слишком часто содержит секреты, токены и служебную конфигурацию.
Масштаб тестов тоже не дает отмахнуться от истории как от лабораторной редкости. Остаточные данные удалось обнаружить на 18 из 24 размещений контейнеров и на 20 из 22 проверенных нижележащих узлов. При этом атакующий не мог выбрать конкретную жертву или конкретный хост, не получал доступ к активно подключенному диску и, по данным Cloudflare, не мог менять чужие данные или ломать чужие workload’ы. Но для инцидентов конфиденциальности чтения иногда хватает с запасом.
Cloudflare подчеркивает, что в ходе проверки исследователи использовали скрипты, которые возвращали агрегированные счетчики, а не содержимое дисков. Компания также изучила логи, телеметрию и исторические данные и не нашла признаков того, что клиентские данные были раскрыты этим способом. Это важная оговорка: публично подтвержден не факт массовой утечки, а возможность пересечения границы изоляции между арендаторами при определенных условиях.
Уязвимость Cloudflare Containers исправили на нескольких уровнях. Cloudflare убрала настройку, из-за которой пропускалось обнуление блоков, вывела из обращения существующие диски контейнеров и очистила кэшированные snapshots, где могли оставаться старые сопоставления блоков. По сути, компания закрыла не только непосредственную дыру, но и хвосты, которые могли пережить простое изменение конфигурации.
Для разработчиков практический вывод скучный, зато полезный: облачная песочница не отменяет дисциплину работы с секретами. .env-файлы, SQLite-базы, профили браузера и credential-файлы не должны лежать в контейнерах просто потому, что так быстрее отладить. Чем больше платформа берет на себя, тем сильнее хочется верить, что нижний слой стерилен. Эта история показывает, что стерильность — не свойство облака по умолчанию, а результат конкретных инженерных процедур.
Для бизнеса сигнал чуть шире. Контейнеры, serverless и edge-рантаймы продают скорость: меньше инфраструктурной рутины, быстрее релизы, ближе к пользователю. Но в мультиарендных средах цена одной неверной настройки хранения может оказаться выше, чем кажется из Jira-задачи с названием вроде «оптимизировать переиспользование блоков». Уязвимость Cloudflare Containers не стала подтвержденной утечкой, но хорошо подсветила слабое место всей модели: клиенты редко видят, где именно проходит граница между их данными и данными соседа по железу, пока кто-нибудь не проверит ее ломом исследовательского интереса.
Следующий вопрос для рынка не в том, случится ли похожая ошибка у другого провайдера, а в том, насколько быстро облачные платформы начнут публично показывать больше деталей о гарантиях очистки, изоляции и жизненном цикле временных дисков. Разработчикам, в свою очередь, придется считать ephemeral-среды не магическим исчезающим ящиком, а обычным носителем данных: все, что попало на диск, потенциально требует такого же уважения, как production-база.