Cloudflare отстрани пробив между клиенти в Containers

Cloudflare затвори уязвимост в Containers и Sandboxes, която позволяваше на клиент с платен план Workers Paid да прочете остатъчни данни от контейнерите на други клиенти, работещи на същия физически сървър. Пробивът е докладван през HackerOne на 4 септември 2026 г. от Орен Йомтов от Accomplish, а последната стъпка от почистването е приключила на 19 септември. Компанията публикува подробен технически разбор съвместно с изследователите на 24 септември.

Къде беше грешката

Всеки контейнер в Cloudflare се изпълнява в собствена Firecracker виртуална машина, а записваемият root диск му се подава като /dev/vdc. Под тази изолация обаче стои общ склад за блокове — Linux device mapper с thin provisioning, при който няколко акаунта делят един и същ pool.

Засегнатите pool-ове са конфигурирани с размер на thin блок 64 KiB и с включена опцията skip_block_zeroing. Тя казва на ядрото да не нулира блок, преди да го подаде на нов том — оптимизация, която има смисъл само когато pool-ът обслужва един и същ собственик на данните. Тук не беше така: когато контейнер бъде изтрит, блоковете му се връщат в общата купчина такива, каквито са.

Оттам нататък атаката е почти тривиална:

# thin блок = 64 KiB, skip_block_zeroing = on
запис на 4 KiB в непокрита област
  -> ядрото заделя цял 64 KiB блок от общия pool
  -> първите 4 KiB са твои
  -> останалите 60 KiB са това, което е било там преди теб

Демонстрацията на Accomplish целенасочено пише в свободното пространство на ext4 файловата система, а после разпознава чуждото съдържание по контролните суми на директорийните блокове — така се отсява какво идва от друга файлова система, а не от собствения диск.

Снимка: Cloudflare

Какво е можело да изтече

Списъкът с типове данни е неприятен: метаданни на файловата система, структури на директории, страници от бази данни и цели SQLite файлове, профили на Chromium, .env файлове и файлове с пароли и ключове. Тоест точно съдържанието, което типичният container workload държи на диска си.

Мащабът също не е единичен случай. Изследователите са намерили остатъчен материал при 18 от 24 тествани разполагания в production и на 20 от 22 проверени сървъра на четири континента, а в събраното са различили около 2700 отделни чужди директорийни inode-а. Освен Containers, същата дискова реализация стои и под Sandboxes и под услугата за рендиране в браузър, така че и те са били засегнати.

Cloudflare подчертава, че реални клиентски данни не са били прочетени: изследователите са пускали само скриптове, които броят намереното агрегирано, а последвалата проверка на логовете не е открила друга активност, съвпадаща с описаната техника. Наградата по bug bounty програмата е изплатена на 14 септември, след като изследователите са потвърдили, че са изтрили събраното.

Хронологията

Реакцията е бърза за уязвимост от този тип — всички часове са UTC:

• 4 септември, 15:26 — доклад през HackerOne
• 4 септември, 18:45 — Cloudflare потвърждава проблема в production
• 4 септември, 21:27 — поправката в runtime е слята
• 7 септември, 06:13 — разгръщането е завършено, започва изчистването на данните
• 14 септември, 10:50 — изследователите потвърждават, че демонстрацията вече не работи
• 19 септември, 15:03 — приключва чистенето на кешираните snapshot-и в цялата инфраструктура

Поправката е в три части: опцията skip_block_zeroing е премахната, всички дискове на контейнери, създадени преди мярката, са изведени от употреба, а кешираните образи са изчистени. От клиентите не се иска нищо — няма настройка за смяна и няма нужда от преразгръщане.

Контекст

Това е шестият публикуван от екипа на Accomplish изход от sandbox от юли 2026 г. насам, след SharedRoot в Claude Cowork, Beltdown в Claude Code, Beltdown2 в Cursor CLI, VMM на Docker и sandbox-а на OpenAI Codex. Общото между тях е, че изолацията се държи на нивото, на което разработчикът я вижда, а се пропуква едно ниво по-надолу — в хипервайзора, в мрежата или, както тук, в слоя за блоково съхранение.

Практическият извод за вас, ако пускате код в чужда multi-tenant среда: не приемайте, че пътят на данните е чист само защото процесът е изолиран. Криптирането на дисковете в контейнера и на чувствителните файлове би направило подобно изтичане безполезно за атакуващия. Струва си и да прегледате какво точно държите в .env файлове по такива платформи — точно те бяха сред най-лесно разпознаваемата плячка.

Сравнете реакцията тук с тази при уязвимости, които се експлоатират активно: при двата 0-day в Citrix NetScaler клиентите чакаха кръпка, докато атаките вървяха. А че дори големите доставчици на AI инфраструктура се борят със същия клас проблеми, показа и случаят, в който OpenAI спря най-мощните си модели след изтичане.