Компания Docker выпустила исправление для критической уязвимости типа «побег из контейнера» в приложении Docker Desktop для Windows и macOS. Проблеме присвоен идентификатор CVE-2025-9074 и оценка 9.3 из 10.0 по шкале CVSS. Уязвимость позволяет вредоносному контейнеру получить неаутентифицированный доступ к внутреннему API движка Docker, что может привести к полной компрометации хост-системы, особенно на платформе Windows. Пользователи Linux не подвержены данной угрозе.
Коренная причина уязвимости заключается в простом упущении: внутренний HTTP API движка Docker был доступен из любого контейнера по адресу
Атака может быть реализована с помощью простого веб-запроса изнутри любого контейнера. На первом этапе злоумышленник отправляет
На втором этапе атакующий отправляет
Последствия эксплуатации уязвимости наиболее серьезны для пользователей Windows. На этой платформе злоумышленник может смонтировать всю файловую систему хоста с правами администратора. Это позволяет не только читать любые конфиденциальные файлы, но и перезаписывать системные DLL-файлы, что в конечном итоге ведет к эскалации привилегий до полного администратора хост-системы.
На macOS риск несколько ниже из-за более строгой изоляции по умолчанию. Приложение Docker Desktop работает с дополнительным уровнем изоляции, и попытка смонтировать пользовательский каталог с хоста вызовет запрос на получение разрешения от пользователя. Тем не менее, уязвимость остается значительной. Атакующий может получить полный контроль над самим приложением Docker и всеми остальными контейнерами. Он также способен создать бэкдор, смонтировав и изменив конфигурационные файлы Docker, что, в отличие от пользовательских каталогов, не требует одобрения пользователя.
Версия Docker для Linux не подвержена этой уязвимости. Причина в архитектурном различии: для своего API она использует «именованный канал» (named pipe) в файловой системе хоста, а не TCP-сокет, как в версиях для Windows и macOS.
Существует два основных вектора атаки. Самый простой — убедить пользователя запустить специально созданный вредоносный образ контейнера. Альтернативный метод — использование уязвимости Server-Side Request Forgery (SSRF) в веб-приложении, работающем в другом, не вредоносном контейнере. Злоумышленник может использовать эту уязвимость для перенаправления запросов на внутренний сокет Docker. Успех этого метода зависит от разрешенных HTTP-методов; полный компромисс возможен в «нишевых случаях», когда разрешены запросы
Уязвимость была обнаружена и исследована специалистами по безопасности Феликсом Буле (Felix Boulet) и Филиппом Дюгре (Philippe Dugre), также известным под псевдонимом "zer0x64", из компании PVOTAL Technologies.
Для устранения угрозы компания Docker выпустила исправления. Всем пользователям Docker Desktop для Windows и macOS необходимо незамедлительно обновиться до версии 4.44.3 или выше.
Изображение носит иллюстративный характер
Коренная причина уязвимости заключается в простом упущении: внутренний HTTP API движка Docker был доступен из любого контейнера по адресу
192.168.65[.]7:2375 без какой-либо аутентификации или контроля доступа. Это позволяет контейнеру напрямую отправлять команды движку Docker. Важно отметить, что для эксплуатации не требуется монтирование сокета Docker в контейнер, что является распространенным условием для подобных атак. Функция Enhanced Container Isolation (ECI) также не способна предотвратить эксплуатацию. Атака может быть реализована с помощью простого веб-запроса изнутри любого контейнера. На первом этапе злоумышленник отправляет
POST-запрос с JSON-нагрузкой на конечную точку API /containers/create. Эта нагрузка инструктирует Docker создать новый контейнер и привязать (смонтировать) весь диск C:\ хост-системы к папке внутри этого нового контейнера, например, /mnt/host/c:/host_root. В команду запуска контейнера также включается инструкция на чтение или запись файлов в смонтированном каталоге. На втором этапе атакующий отправляет
POST-запрос на конечную точку /containers/{id}/start. В результате запускается созданный контейнер, который немедленно выполняет вредоносную команду при запуске. Это предоставляет злоумышленнику неограниченный доступ к файловой системе хоста, позволяя ему вырваться за пределы изолированной среды контейнера и получить несанкционированный доступ к файлам пользователя. Последствия эксплуатации уязвимости наиболее серьезны для пользователей Windows. На этой платформе злоумышленник может смонтировать всю файловую систему хоста с правами администратора. Это позволяет не только читать любые конфиденциальные файлы, но и перезаписывать системные DLL-файлы, что в конечном итоге ведет к эскалации привилегий до полного администратора хост-системы.
На macOS риск несколько ниже из-за более строгой изоляции по умолчанию. Приложение Docker Desktop работает с дополнительным уровнем изоляции, и попытка смонтировать пользовательский каталог с хоста вызовет запрос на получение разрешения от пользователя. Тем не менее, уязвимость остается значительной. Атакующий может получить полный контроль над самим приложением Docker и всеми остальными контейнерами. Он также способен создать бэкдор, смонтировав и изменив конфигурационные файлы Docker, что, в отличие от пользовательских каталогов, не требует одобрения пользователя.
Версия Docker для Linux не подвержена этой уязвимости. Причина в архитектурном различии: для своего API она использует «именованный канал» (named pipe) в файловой системе хоста, а не TCP-сокет, как в версиях для Windows и macOS.
Существует два основных вектора атаки. Самый простой — убедить пользователя запустить специально созданный вредоносный образ контейнера. Альтернативный метод — использование уязвимости Server-Side Request Forgery (SSRF) в веб-приложении, работающем в другом, не вредоносном контейнере. Злоумышленник может использовать эту уязвимость для перенаправления запросов на внутренний сокет Docker. Успех этого метода зависит от разрешенных HTTP-методов; полный компромисс возможен в «нишевых случаях», когда разрешены запросы
POST, PATCH или DELETE. Уязвимость была обнаружена и исследована специалистами по безопасности Феликсом Буле (Felix Boulet) и Филиппом Дюгре (Philippe Dugre), также известным под псевдонимом "zer0x64", из компании PVOTAL Technologies.
Для устранения угрозы компания Docker выпустила исправления. Всем пользователям Docker Desktop для Windows и macOS необходимо незамедлительно обновиться до версии 4.44.3 или выше.
