В Docker Desktop обнаружены критические уязвимости: исправлены две бреши в механизмах вывода ИИ-моделей

Docker выпустила внеплановое обновление безопасности, закрывающее сразу две критические уязвимости своего продукта Docker Desktop. Ошибки, зарегистрированные в базе Common Vulnerabilities and Exposures (CVE) как CVE-2026-5817 и CVE-2026-5843, позволяют злоумышленнику выполнить произвольный код на хост-системе прямо из контейнера. Под ударом оказались все пользователи Docker Desktop версий ниже 4.71.0, причем для эксплуатации не требовалось сложных привилегий. Проблема тем серьезней, что затронуты модули, которые используются для работы с современными алгоритмами искусственного интеллекта.

Детали уязвимостей

Обе уязвимости были обнаружены в компоненте Docker Model Runner - это специальный сервис, предназначенный для локального запуска и тестирования ИИ-моделей. Первая брешь, CVE-2026-5817, была устранена еще 7 апреля в релизе 4.68.0. Она затрагивала бэкенд вывода vllm-metal, который основан на популярной библиотеке vLLM (фреймворк для ускоренного логического вывода больших языковых моделей). Однако, судя по всему, исправление оказалось неполным. Уже 27 апреля в версии 4.71.0 Docker пришлось латать похожую проблему, но уже в другом бэкенде - MLX (фреймворк для машинного обучения на устройствах Apple Silicon). Обе ошибки относились к одному классу: контейнер получал возможность выполнять код на хост-машине.

Как вообще возможна такая атака? В обычной ситуации контейнер Docker изолирован от базовой операционной системы с помощью механизмов пространства имен и контрольных групп. Однако компонент Model Runner предоставляет специфический доступ к аппаратным ресурсам - графическому процессору (GPU) и нейронным движкам, что само по себе расширяет границу изоляции. Уязвимости CVE-2026-5817 и CVE-2026-5843 связаны с некорректной проверкой данных, передаваемых из контейнера в модуль логического вывода. Иными словами, вредоносная программа внутри контейнера могла отправить специально сформированный запрос, который приводил к переполнению буфера или подмене указателя. В результате хост-система начинала выполнять код, сгенерированный атакующим.

С технической точки зрения интересен сам вектор атаки. В отличие от классических уязвимостей в службах оркестрации или демоне Dockerd, эти бреши атакуют не само ядро платформы, а её надстройку для работы с искусственным интеллектом. Это симптом общей тенденции, ведь все больше компаний внедряют контейнеры именно для развертывания моделей машинного обучения. Стандартные средства защиты, такие как системы обнаружения вторжений (IDS - решения, отслеживающие подозрительную сетевую активность) или сканеры образов, здесь могут не сработать, потому что вредоносная нагрузка (полезные данные атаки) передается внутри легитимного трафика между приложением и бэкендом вывода.

Последствия эксплуатации могут быть крайне серьезными. Выполнение кода на хост-системе означает, что злоумышленник получает контроль не над отдельным контейнером, а над всей виртуальной машиной или рабочим местом разработчика. Дальнейшие действия очевидны: кража ключей доступа к облачным реестрам, компрометация системы непрерывной интеграции, установка программ-шпионов или шифровальщиков (программ-вымогателей, блокирующих данные с требованием выкупа). Особенно уязвимы корпоративные среды, где на одном хосте запускаются десятки контейнеров. Один скомпрометированный образ может стать трамплином для движения по всей сети.

Прежде всего, необходимо проверить версию Docker Desktop на всех машинах разработки и серверах. Если она ниже 4.71.0, обновление должно быть проведено незамедлительно, желательно в рамках процедуры управления изменениями. В качестве временной меры, если обновление невозможно, можно отключить модуль Docker Model Runner. Однако это лишит пользователей возможности локального тестирования ИИ-моделей. Кроме того, стоит пересмотреть политику доступа к контейнерным реестрам, чтобы исключить случайное внедрение вредоносных образов.

Необходимо подчеркнуть, что эти инциденты - еще одно напоминание о том, что безопасность контейнерной инфраструктуры не ограничивается настройкой прав пользователя или сканированием базовых образов. Каждый новый функциональный модуль, особенно связанный с аппаратным ускорением, расширяет поверхность атаки. Разработчикам, которые активно используют Docker Desktop для работы с искусственным интеллектом, следует не только своевременно устанавливать патчи, но и внедрять проверку сигнатур вызовов к бэкендам вывода, а также мониторить аномальную активность на уровне межпроцессного взаимодействия.

Ссылки на исходные бюллетени уже доступны: безопасную версию можно загрузить с официального портала Docker, а полное описание уязвимостей опубликовано в базе CVE. Пользователям рекомендуется изучить оба документа, чтобы понять, какие именно сценарии атак были предотвращены. Впрочем, главный урок очевиден: в мире, где контейнеры все активнее используются для ИИ-нагрузок, старые правила изоляции требуют пересмотра.