Уязвимость Cloudflare Containers позволяла одному клиенту читать фрагменты данных, которые оставались на диске после контейнеров других клиентов. Речь не о доступе к живым workload’ам, а о 64-килобайтных блоках, которые сервис повторно выдавал новым контейнерам без очистки. Для разработчиков и компаний, запускающих код в shared-инфраструктуре, это неприятное напоминание: изоляция заканчивается там, где кто-то выключил wipe ради скорости или удобства.
О проблеме сообщает The Hacker News. Баг нашел Орен Йомтов из компании Accomplish и передал Cloudflare 4 сентября 2026 года через bug bounty. По данным Cloudflare, уязвимость затронула Cloudflare Containers и Cloudflare Sandboxes — сервис для запуска недоверенного кода, в том числе кода, написанного AI-агентами. Компания заявила, что исправила проблему во всей инфраструктуре, а клиентам ничего делать не нужно.
Суть ошибки оказалась почти прозаичной. Cloudflare Containers запускает пользовательские программы в контейнерах на общих серверах, а конкретную машину выбирает сама Cloudflare. Для дисков использовался Linux-механизм thin provisioning: хранилище выделяется блоками по 64 КБ. Когда контейнер удаляли, его блоки возвращались в общий пул. Этот пул был настроен так, что блок не очищался перед повторной выдачей новому контейнеру, хотя очистка обычно является поведением по умолчанию.
Исследователи показали, что новый контейнер мог записать небольшой 4-килобайтный фрагмент в свободное место, а затем прочитать весь блок на низком уровне. Остальные 60 КБ содержали данные от предыдущего контейнера. По результатам производственных тестов остаточные данные удалось найти в 18 из 24 попыток. Cloudflare выбирала серверы сама, а исследователи дополнительно сообщили об успешном воспроизведении на 20 из 22 физических машин в четырех регионах мира.
Содержимое этих блоков было разным: структуры директорий, страницы баз данных, полноценные SQLite-базы. В описании исследователей также упоминались списки файлов, профили Chromium, .env-файлы и файлы с учетными данными. Важная оговорка: атакующий не мог выбрать, чьи именно данные ему достанутся, и речь шла не о текущем контейнере другого клиента, а об остатках после уже завершенных workloads. Это не делает инцидент безобидным. Если в остатках лежит .env с токеном, базе данных уже не нужно быть «живой», чтобы доставить владельцу много интересного вечера.
Cloudflare подчеркивает, что исследователи не передавали компании чужие имена, идентификаторы, пароли или восстановленное содержимое файлов. Их скрипты выводили счетчики и результаты проверки форматов, а не сами данные. Компания также заявила, что полученные материалы были удалены безопасно после отправки отчета. Доказательств, что через эту уязвимость можно было менять чужие данные или останавливать чужие нагрузки, нет.
Исправление прошло в два этапа. Сначала Cloudflare снова включила очистку блоков перед выдачей новым контейнерам. 14 сентября исследователи подтвердили, что их proof of concept больше не работает. Но этого было мало: уже сопоставленные с работающими контейнерами диски и кэши подготовленных image layers на серверах могли по-прежнему содержать старые данные. Поэтому Cloudflare вывела из эксплуатации все работающие container disks, очистила кэши и перезапустила серверы в часы низкой нагрузки. Полная зачистка завершилась 19 сентября, публичное раскрытие вышло 25 сентября.
Компания также построила сигнатуры по proof of concept исследователей и собственной реализации атаки, а затем прогнала их по сохраненным журналам дисковой активности. По словам Cloudflare, следы нашлись только у исследователей и инженеров компании, которые проводили авторизованные проверки. При этом Cloudflare не указала, за какой период хранились эти записи и когда именно небезопасная настройка появилась в продакшене. Поэтому длительность окна риска из опубликованных данных неясна.
История особенно болезненна из-за контекста. Accomplish описывает эту находку как шестой опубликованный с июля escape из code sandbox: до этого команда сообщала о проблемах в Anthropic Claude Cowork и Claude Code, CLI-инструменте Cursor, Docker и OpenAI Codex. Исследователи отдельно утверждают, что та же дисковая схема затрагивала Cloudflare Browser Run, но в публикации Cloudflare названы только Containers и Sandboxes. Для рынка это уже не серия разрозненных багов, а проверка базовой идеи: можно ли безопасно запускать чужой, в том числе AI-сгенерированный, код на общей инфраструктуре без постоянной паранойи на уровне дисков, кэшей и временных слоев.
Для команд, которые используют контейнерные платформы, главный вывод практичный: секреты не должны переживать контейнер дольше, чем нужно, а временные файлы с токенами, профили браузеров и локальные SQLite-базы не стоит считать «внутренним мусором». Уязвимость Cloudflare Containers закрыта, но похожие ошибки будут всплывать везде, где скорость запуска, мультиарендность и запуск недоверенного кода встречаются в одной стойке. Следующий вопрос для облачных провайдеров уже не в том, смогут ли они изолировать контейнеры на уровне API, а в том, насколько честно они проверяют самые скучные слои инфраструктуры — диски, пулы блоков и кэши, где обычно и прячется настоящая инженерная драма.