Коротко: 24 сентября 2026 года Cloudflare раскрыла уязвимость в платформе Containers (и построенных на ней Sandboxes): клиент с платным тарифом Workers Paid мог прочитать до 60 КБ остаточных данных предыдущего арендатора того же физического сервера — каталоги, базы SQLite, профили Chromium и файлы .env с секретами. Причина — одна настройка хранилища на основе Linux dm-thin. Уязвимость нашёл исследователь Орен Йомтов из компании Accomplish 4 сентября через программу bug bounty на HackerOne; Cloudflare устранила проблему к 19 сентября и не нашла следов реальной эксплуатации до раскрытия.
Что произошло
Cloudflare Containers позволяет клиентам запускать изолированные рабочие нагрузки — от песочниц для ИИ-агентов до пользовательского кода — на виртуальных машинах Firecracker. Диски этих контейнеров Cloudflare организовала через thin-provisioning: физическое место на диске резервируется блоками по 64 КБ только когда контейнер реально туда пишет, а не заранее — так экономится место на общем сервере.
Проблема была в параметре skip_block_zeroing: когда контейнер удалялся, его физические блоки возвращались в общий пул, из которого брали диск уже другие клиенты, — но сами блоки предварительно не обнулялись. Записав всего 4 КБ новых данных в такой переиспользованный блок, следующий арендатор мог прочитать оставшиеся 60 КБ чужой информации на «сыром» уровне диска.
Что именно можно было прочитать
По данным Cloudflare и независимых исследователей, в 18 из 24 протестированных размещений обнаружились реальные остатки чужих рабочих нагрузок: структуры каталогов, страницы баз данных, в том числе целые базы SQLite, профили браузера Chromium и файлы .env с переменными окружения — в них разработчики нередко хранят пароли, API-ключи и токены доступа. Уязвимость также затрагивала сервис Cloudflare Sandboxes, построенный поверх Containers.
Важная оговорка: выбрать конкретную жертву, сервер или тип данных заранее было нельзя — атакующий получал случайный фрагмент от того арендатора, который до него занимал тот же физический хост. Cloudflare заявила, что при проверке собственной телеметрии дисковых операций не нашла признаков того, что кто-то использовал эту технику для реальной кражи данных до момента устранения.
Что это значит для обычного пользователя
Напрямую под риском — не рядовые пользователи VPN, а компании и разработчики, которые запускали код в Cloudflare Containers: именно их секреты и данные теоретически могли прочитать соседи по серверу. Но история показательна шире: даже у крупнейшего провайдера облачной инфраструктуры одна забытая настройка хранения данных способна месяцами оставлять чужие пароли и токены буквально «под рукой» у любого платящего клиента. Если вы храните личные данные в облачных сервисах, периодически проверяйте, не всплыли ли ваши учётные данные в публичных утечках — это можно сделать по инструкции как проверить утечку персональных данных.
Для собственного трафика в быту урок другой: шифрование соединения защищает данные в пути, а не то, как провайдер хранит их на своих серверах. Используя LiMP VPN, вы доверяете сервису обработку трафика — поэтому важно выбирать провайдера, который публично и быстро закрывает такие инциденты, как это сделала Cloudflare, а не замалчивает их.
Как защититься, если вы использовали Cloudflare Containers
- Патч Cloudflare применила автоматически 19 сентября 2026 года — никаких действий со стороны клиентов не требуется, но если ваш workload хранил секреты в файлах
.envвнутри контейнера, стоит ротация этих ключей и паролей на всякий случай. - Не храните долгоживущие секреты (пароли, API-ключи, токены) в файловой системе контейнера или песочницы — выносите их в менеджер секретов с ограниченным временем жизни.
- Рядовым пользователям, чьи данные обрабатывались через сервисы на Cloudflare Containers, специальных действий не требуется: Cloudflare подтвердила отсутствие следов эксплуатации до раскрытия уязвимости.
- Общая гигиена остаётся актуальной: используйте уникальные пароли для разных сервисов и менеджер паролей, чтобы утечка на стороне одного поставщика не открывала доступ к другим аккаунтам.