Вредоносный код, работающий внутри виртуальной машины Docker Sandboxes на macOS, мог покинуть каталог проекта, предоставленный ему в общий доступ, и читать или изменять файлы в любом другом месте хоста, предупреждает Docker в сообщении о безопасности от 15 сентября.
Утечка происходит с правами учетной записи хоста, которая запускает виртуальную машину. Уязвимость, CVE-2026-77179, имеет критический уровень опасности, затрагивает версии от 0.28.0 до 0.42.0 (не включая ее) на macOS и была исправлена в версии 0.42.0 7 сентября.
Docker Sandboxes запускает каждый агент для написания кода в своей собственной небольшой виртуальной машине с общим каталогом проекта. Код, который мог покинуть ее, — это все, что выполняется внутри этой машины, например, агент для написания кода, который был обращен против своего пользователя, или что-либо вредоносное, что агент устанавливает и запускает.
Docker не сообщал об использовании этой уязвимости. CISA в своей оценке записи CVE указывает на отсутствие эксплуатации, и уязвимость не входит в каталог известных эксплуатируемых уязвимостей CISA по состоянию на версию каталога от 16 сентября.
Для эксплуатации уязвимости требуется вредоносный код внутри песочницы, а защита хоста от того, что запускает агент, — это именно то, для чего предназначена песочница. Агент устанавливает пакеты и выполняет команды с помощью sudo внутри виртуальной машины, а в документации по изоляции Docker говорится, что граница гипервизора «является средством контроля изоляции, а не разделением привилегий внутри ВМ».
Утечка происходит через сервер virtio-fs на хосте, который является частью файлового обмена между Mac и виртуальной машиной. Он следовал символическим ссылкам при повторном открытии удаленного файла из сохраненного пути, сообщает Docker.
Гостевая система, то есть все, что выполняется внутри виртуальной машины, могла заменить родительский каталог символической ссылкой, а затем читать или изменять файлы от имени пользователя VMM — учетной записи хоста, под которой работает монитор виртуальной машины, — что «потенциально может привести к выполнению кода на хосте», заявляет Docker.
В документации Docker с марта указывалось, что символические ссылки, указывающие за пределы рабочей области (термин Docker для общего каталога проекта), не отслеживаются.
Тот же выпуск исправляет вторую уязвимость, CVE-2026-79994, оцененную Docker как «Высокая» с баллом CVSS 8.7, в ретрансляторе, который позволяет песочнице подключаться к сокетам домена Unix в пределах ее авторизованной рабочей области.
Ретранслятор проверял, находится ли путь к сокету в рабочей области, а затем переподключался, используя имя пути. Гостевая система, которая заменила каталог вдоль этого пути символической ссылкой между проверкой и подключением, могла заставить хост подключиться к любому сокету AF_UNIX за пределами рабочей области, «раскрывая данные или возможности на стороне хоста, предоставляемые этим сокетом», сообщает Docker.
Эта уязвимость затрагивает версии с 0.37.0 по 0.41.9, но не 0.42.0. Docker указывает, что первая уязвимость специфична для macOS, но не указывает платформу для нее, хотя Docker Sandboxes работает на macOS, Windows и Linux. Оценка CISA также указывает на отсутствие эксплуатации, и уязвимость также не входит в каталог KEV.
По умолчанию `sbx run` предоставляет общий доступ к текущему каталогу в песочницу с правами на чтение и запись. Режим клонирования работает только тогда, когда проект является репозиторием Git, и устанавливается при создании песочницы, поэтому существующую песочницу необходимо удалить и создать заново с флагом `–clone`.
Режим клонирования защищает репозиторий от изменений, но не от чтения. Репозиторий монтируется в режиме только для чтения по пути `/run/sandbox/source`, а неотслеживаемые файлы, такие как `.env`, остаются доступными для чтения внутри песочницы, согласно документации Docker.
Docker опубликовал записи CVE и консультативное уведомление 15 сентября, через восемь дней после выпуска версии 0.42.0.
В заметках к выпуску 0.42.0 на GitHub и на сайте документации Docker по состоянию на 17 сентября ни одна из CVE не упоминается. Среди обычных исправлений указано одно: «процесс в песочнице мог заставить демон открыть транспорт D-Bus хоста и выполнить произвольную команду на хосте». Docker не связал это исправление ни с одной из CVE.
В записи для CVE-2026-79994 изначально указывалась версия 0.41.0 как первая исправленная версия и была ссылка на несуществующую страницу выпуска 0.41.0. Docker исправил обе на 0.42.0 примерно через час после публикации записи 15 сентября.
Docker благодарит Орена Йомтова из accomplish.ai за обнаружение CVE-2026-77179 и Юрре ван Бергена из ThreatNotify за обнаружение CVE-2026-79994.
В апреле Cyera Research Labs описала, как агент для написания кода с внедренным запросом внутри песочницы на базе Docker мог быть обманут для использования отдельной уязвимости Docker Engine против своего хоста.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Swati Khandelwal
