Две уязвимости в Docker Sandboxes позволяют вредоносной гостевой системе выйти за границы изолированной среды и добраться до ресурсов хоста. Исправления вошли в выпуск 0.42.0 от 7 сентября. Первая, CVE-2026-77179, даёт читать и изменять произвольные файлы на macOS от имени пользователя монитора виртуальных машин, вплоть до выполнения кода на самом хосте. Вторая, CVE-2026-79994, открывает доступ к доменным Unix-сокетам за пределами общей рабочей области. Публикация записей в каталоге уязвимостей состоялась 15 сентября.
Детали уязвимостей
Docker Sandboxes запускает код в изолированной среде. Основная работа идёт в гостевой системе, а обмен данными с хостом - через общие каталоги. Такой схемой пользуются, когда нужно прогнать непроверенный код, сборку или автоматического агента, не подпуская его к основной машине. Смысл конструкции в том, что гость заведомо недоверенный. Обе уязвимости бьют именно по этой границе: гость получает то, что ему не должно быть доступно.
Первую проблему породил хост-компонент virtio-fs, который отдаёт гостевой системе доступ к общим каталогам. Когда открытый файл исчезал из каталога, сервер заново открывал его по сохранённому пути и при этом шёл по символическим ссылкам. Вредоносная гостевая система подменяла родительский каталог символической ссылкой, и последующие обращения уходили за пределы общей рабочей области. Читать и править можно было любые файлы хоста, доступные пользователю, под которым работает виртуальная машина. Такой доступ к файловой системе означает и потенциальное выполнение кода на хосте, поскольку этому пользователю обычно доступны конфигурационные файлы и исполняемые файлы. Оценка по CVSS 4.0 - 9.4 из 10. Слабость отнесли к категории CWE-59, то есть к некорректному разрешению ссылок перед обращением к файлу. Уязвимы версии с 0.28.0 и до 0.42.0 не включительно, причём только на macOS.
Вторая уязвимость устроена сложнее и связана с передачей соединений. Промежуточный узел, который перенаправляет запросы от гостевой системы к доменным Unix-сокетам хоста, сначала проверял, что путь к нужному сокету лежит внутри разрешённой рабочей области, а подключался позже и по имени пути. Между проверкой и подключением оставался промежуток времени. За этот промежуток вредоносная гостевая система успевала подменить промежуточный каталог символической ссылкой, и хост соединялся с произвольным сокетом за пределами общей рабочей области. Через чужой сокет утекают данные или открываются возможности, которые он предоставляет на стороне хоста. Перед нами состояние гонки, или, формулируя точнее, расхождение между моментом проверки и моментом использования. Категория слабости - CWE-367. Оценка по CVSS 4.0 - 8.7 из 10. Затронуты версии с 0.37.0 и до 0.42.0 не включительно, без привязки к платформе.
Обе уязвимости требуют, чтобы злоумышленник уже управлял кодом внутри песочницы. Вектор локальный, учётные данные и действия пользователя не нужны. Однако именно такой сценарий и заложен в назначение инструмента: запускать чужой код, не доверяя ему. Человек, который скачал репозиторий с вредоносной сборкой или подключил стороннего агента, получает атакующего прямо внутри изоляции - и дальше всё зависит от прочности её стенок. Разница между двумя случаями в сложности. Для первой уязвимости достаточно подготовить символическую ссылку и дождаться, пока сервер обратится к файлу повторно. Во втором случае нужно успеть подменить каталог ровно в тот момент, когда проверка уже пройдена, а соединение ещё не установлено. Поэтому вторая задача сложнее и менее предсказуема, хотя обе записи описывают одну и ту же ошибку проектирования: доверие к имени пути, которое гость может переиграть.
Обновление до 0.42.0 закрывает обе уязвимости. Если по каким-то причинам перейти на новую версию нельзя, Docker предлагает два ограничения: работать в режиме клонирования и не подключать каталоги хоста с правом записи. Первое снижает ценность подмены пути, второе убирает саму возможность что-то изменить на хосте через общий каталог. Обе меры не заменяют обновление, а лишь уменьшают ущерб на время. Пользователям, которые держат песочницы для сборки недоверенного кода, стоит проверить версию без промедления: окно между 0.28.0 и 0.42.0 открыто давно, а сведения об уязвимостях теперь опубликованы.
История показательна не масштабом, а классом ошибок. Символические ссылки и расхождения между проверкой и использованием годами остаются надёжным способом пробить изоляцию. Проверка пути ненадёжна по своей природе: пока код сверяет строку с именем файла или каталога, злоумышленник может поменять то, на что это имя указывает. Надёжнее работать с уже открытыми объектами и не переходить по ссылкам там, где ожидается обычный каталог. Для песочниц цена такой ошибки особенно высока. Изоляция здесь - единственный барьер между недоверенным кодом и рабочей машиной, и стоит он ровно столько, сколько стоит самая слабая проверка на её границе.
Ссылки
- https://docs.docker.com/security/security-announcements/#docker-sandboxes-0420-security-update-cve-2026-77179-and-cve-2026-79994
- https://www.cve.org/cverecord?id=CVE-2026-77179
- https://www.cve.org/cverecord?id=CVE-2026-79994
