В июле 2024 года была раскрыта уязвимость CVE-2024-41110 с максимальной степенью критичности в Docker Engine. Разработчики выпустили патч. Казалось бы, закрыли. Но исследователи из Cyera Research Labs обнаружили, что заплатка не сработала как следует: неполное исправление породило новую уязвимость CVE-2026-34040 с оценкой CVSS 8.8, которая позволяет полностью обойти авторизацию в Docker и получить root-доступ к хостовой машине.
Механизм атаки прямолинейный до неудобства. Docker API принимает запросы на создание контейнеров. Если тело такого запроса превышает 1 МБ, Docker-демон отбрасывает его до отправки плагину авторизации (AuthZ). Плагин получает запрос без тела, не видит ничего подозрительного и одобряет его. Демон при этом обрабатывает исходный полный запрос и создаёт привилегированный контейнер с доступом к файловой системе хоста. Атака работает против каждого AuthZ-плагина в экосистеме, который полагается на анализ тела запроса — то есть против всех.
Уязвимость обнаружили независимо несколько исследователей: Асим Виладий Оглу Манизада, Коди и Олег Конько. Владимир Токарев из Cyera Research Labs написал технический отчёт и передал его в The Hacker News. Адвизори от сопровождающих Docker Engine вышел в конце прошлого месяца. Исправление появилось в Docker Engine версии 29.3.1.
После получения доступа к файловой системе хоста атака не заканчивается — она там начинается. Из смонтированного хостового окружения можно вытащить ключи AWS, SSH-ключи для входа на продакшн-серверы, конфиги Kubernetes (тот самый
Отдельная и по-настоящему неприятная история связана с ИИ-агентами. Cyera Research Labs описали два сценария, оба рабочие. Первый: агент вроде OpenClaw, работающий внутри Docker-sandbox, обрабатывает репозиторий с GitHub в рамках обычного рабочего процесса разработчика. Если в репозитории спрятана инструкция для prompt injection, агент исполнит вредоносный код, который и сформирует раздутый HTTP-запрос с padding'ом больше 1 МБ.
Второй сценарий хуже, потому что не требует заражённого репозитория вообще. Токарев описал ситуацию: агенту ставят законную задачу — скажем, «разберись с OOM-ошибкой в Kubernetes». В процессе работы агент обращается к файлам вроде
Это меняет разговор о безопасности контейнерных окружений. Раньше вектор атаки предполагал человека с намерением взломать систему. Теперь достаточно ИИ-агента с доступом к Docker API и задачей, которая упёрлась в ограничение авторизации. Граница между автоматизацией и эксплуатацией становится размытой — и это не метафора.
Обновление до Docker Engine 29.3.1 закрывает уязвимость. Но Токарев указывает на архитектурные меры, которые ограничивают ущерб даже при успешной атаке. Rootless Mode: в этом режиме root внутри привилегированного контейнера отображается на непривилегированный UID хоста. Полной компрометации хоста не происходит — только компрометация непривилегированного пользователя. Для сред, где полностью rootless-режим не применим, флаг
Изображение носит иллюстративный характер
Механизм атаки прямолинейный до неудобства. Docker API принимает запросы на создание контейнеров. Если тело такого запроса превышает 1 МБ, Docker-демон отбрасывает его до отправки плагину авторизации (AuthZ). Плагин получает запрос без тела, не видит ничего подозрительного и одобряет его. Демон при этом обрабатывает исходный полный запрос и создаёт привилегированный контейнер с доступом к файловой системе хоста. Атака работает против каждого AuthZ-плагина в экосистеме, который полагается на анализ тела запроса — то есть против всех.
Уязвимость обнаружили независимо несколько исследователей: Асим Виладий Оглу Манизада, Коди и Олег Конько. Владимир Токарев из Cyera Research Labs написал технический отчёт и передал его в The Hacker News. Адвизори от сопровождающих Docker Engine вышел в конце прошлого месяца. Исправление появилось в Docker Engine версии 29.3.1.
После получения доступа к файловой системе хоста атака не заканчивается — она там начинается. Из смонтированного хостового окружения можно вытащить ключи AWS, SSH-ключи для входа на продакшн-серверы, конфиги Kubernetes (тот самый
kubeconfig). Это прямой путь к захвату облачных аккаунтов и кластеров. Если Docker работает на узле Kubernetes-кластера — компрометируется весь кластер. Отдельная и по-настоящему неприятная история связана с ИИ-агентами. Cyera Research Labs описали два сценария, оба рабочие. Первый: агент вроде OpenClaw, работающий внутри Docker-sandbox, обрабатывает репозиторий с GitHub в рамках обычного рабочего процесса разработчика. Если в репозитории спрятана инструкция для prompt injection, агент исполнит вредоносный код, который и сформирует раздутый HTTP-запрос с padding'ом больше 1 МБ.
Второй сценарий хуже, потому что не требует заражённого репозитория вообще. Токарев описал ситуацию: агенту ставят законную задачу — скажем, «разберись с OOM-ошибкой в Kubernetes». В процессе работы агент обращается к файлам вроде
kubeconfig, получает отказ от AuthZ-плагина и начинает разбираться, как обойти ограничение. Для этого не нужны ни специальные инструменты, ни готовый эксплойт, ни повышенные привилегии — только стандартные знания об HTTP и доступ к документации Docker API. Агент самостоятельно конструирует запрос нужного размера и обходит блокировку. Это меняет разговор о безопасности контейнерных окружений. Раньше вектор атаки предполагал человека с намерением взломать систему. Теперь достаточно ИИ-агента с доступом к Docker API и задачей, которая упёрлась в ограничение авторизации. Граница между автоматизацией и эксплуатацией становится размытой — и это не метафора.
Обновление до Docker Engine 29.3.1 закрывает уязвимость. Но Токарев указывает на архитектурные меры, которые ограничивают ущерб даже при успешной атаке. Rootless Mode: в этом режиме root внутри привилегированного контейнера отображается на непривилегированный UID хоста. Полной компрометации хоста не происходит — только компрометация непривилегированного пользователя. Для сред, где полностью rootless-режим не применим, флаг
--userns-remap даёт аналогичную защиту через пространства имён пользователей. Оба подхода не устраняют уязвимость, но сужают радиус поражения до управляемого.
