Как Docker Sandboxes позволял гостевому коду добраться до файлов macOS?

15 сентября 2026 года Docker предупредила о критической уязвимости Docker Sandboxes: вредоносный код внутри виртуальной машины мог выйти за пределы общего каталога проекта и читать либо изменять другие файлы на macOS. Доступ выполнялся с правами учётной записи, запустившей виртуальную машину. Сведений о реальных атаках компания не обнаружила.
Как Docker Sandboxes позволял гостевому коду добраться до файлов macOS?
Изображение носит иллюстративный характер

Уязвимость CVE-2026-77179 получила 9,4 балла по CVSS и затрагивала сервер virtio-fs в версиях Docker Sandboxes от 0.28.0 до всей ветки 0.41.x. Гостевая система могла заменить родительский каталог символической ссылкой и тем самым обойти границы разрешённой директории. После этого файлы читались или менялись от имени пользователя VMM, то есть владельца процесса монитора виртуальной машины. При удачном подборе цели это могло закончиться выполнением кода на хосте.
Риск особенно неприятен из-за назначения Docker Sandboxes. Каждый ИИ-агент для программирования помещается в небольшую виртуальную машину, куда передаётся каталог проекта. Потенциальным противником может оказаться агент, которым управляют через инъекцию в промпт, либо вредоносный пакет, установленный самим агентом. Внутри VM агенту разрешено ставить программы и запускать команды через sudo. Docker прямо указывает: защиту здесь даёт граница гипервизора, а не разграничение привилегий внутри гостевой системы. Если эта граница протекает, внутренний root уже совсем не безобиден.
Вторая ошибка, CVE-2026-79994, находилась в механизме ретрансляции Unix-сокетов между гостем и хостом. Ей присвоили высокий уровень опасности и 8,7 балла по CVSS; уязвимы версии 0.37.0–0.41.9. Из-за гонки TOCTOU гость успевал заменить уже проверенный каталог символической ссылкой до установки соединения. В результате хост можно было заставить подключиться к произвольному сокету AF_UNIX за пределами разрешённого рабочего каталога, получив доступ к данным или функциям локальных служб. Конкретная платформа в записи не названа; Docker Sandboxes поддерживает macOS, Windows и Linux.
Обе ошибки исправлены в Docker Sandboxes 0.42.0, выпущенной 7 сентября 2026 года. На 17 сентября актуальной была версия 0.43.0, опубликованная 15 сентября. Практическое действие одно: обновиться до 0.42.0 или новее. Docker и CISA оценивали статус эксплуатации как none; в редакции каталога CISA Known Exploited Vulnerabilities от 16 сентября ни одной из двух CVE не было.
Если немедленное обновление невозможно, Docker советует перейти в режим клонирования и не добавлять монтирования хоста с правом записи. Старые песочницы придётся удалить и создать заново с параметром:
--cloneРежим требует Git-репозитория и монтирует его только для чтения по адресу /run/sandbox/source. От изменения файлов это спасает, от чтения — нет. Незакоммиченные данные, включая файл .env, остаются видимыми внутри песочницы. Это существенная оговорка: по умолчанию команда sbx run передаёт текущий каталог с правами чтения и записи.
Хронология публикации вышла неровной. Исправленная версия 0.42.0 появилась 7 сентября, а записи CVE и бюллетень Docker — лишь 15 сентября, через восемь дней. На 17 сентября примечания к выпуску 0.42.0 не называли ни CVE-2026-77179, ни CVE-2026-79994. Зато там упоминалась ошибка, позволявшая процессу из песочницы заставить демон открыть на хосте транспорт D-Bus и выполнить произвольную команду. Docker не связала этот пункт ни с одной из рассматриваемых уязвимостей.
В записи CVE-2026-79994 сначала ошибочно указали версию 0.41.0 как первую исправленную и дали ссылку на несуществующую страницу выпуска. Примерно через час после публикации 15 сентября Docker исправила оба пункта: безопасной версией стала 0.42.0, ссылка тоже была заменена. Для администраторов это лишний повод проверять установленную сборку, а не полагаться на раннюю редакцию карточки CVE.
CVE-2026-77179 обнаружил Орен Йомтов (Oren Yomtov) из . Автором находки CVE-2026-79994 указан Юрре ван Берген (Jurre van Bergen) из ThreatNotify. Обе работы показывают один и тот же слабый участок: проверка пути бесполезна, если гость способен подменить компонент этого пути до фактического обращения хоста.
Предупреждение появилось не на пустом месте. В апреле 2026 года Cyera Research Labs описала сценарий, при котором агент для программирования после инъекции в промпт пытался использовать отдельную уязвимость Docker Engine против хостовой системы. Новые CVE добавили к этой модели более прямые маршруты: выход через общий каталог и обращение к постороннему Unix-сокету. Поэтому секреты вроде .env разумно вообще не передавать агенту, даже когда репозиторий подключён только для чтения.


Новое на сайте

20949Старая техника Apple получила заплатку для опасной уязвимости 20948Как три уязвимости открыли ShinyHunters путь к серверам PeopleSoft? 20947Может ли ИИ сам собрать уязвимости в работающий взлом? 20946Уязвимость CVSS 10.0 в LXD и MicroCloud позволяет выдать себя за доверенного клиента 20945Google разрешит устанавливать приложения из сторонних магазинов одним нажатием 20944Взлом Chainalysis: что могли увидеть атакующие 20943Oracle E-Business Suite под прицелом: попытки атак начались вскоре после исправления 20942Фишинг без кражи пароля: как Skyw4lker атакует Microsoft 365 20941ИИ в SOC: быстрее расследовать, не теряя контроля 20940Могут ли уязвимости GoAhead подорвать доверие к TLS? 20939Adobe устранила критические уязвимости в Campaign Classic и Connect 20938Как взломанный скрипт DebugBear помог похитить у трейдеров Polymarket около $2,7 млн? 20937Как ошибка в сетевой загрузке UEFI обходит защиту до запуска Secure Boot? 20936Silent Train: сеть скрытных атак Volt Typhoon 20935Как ссылка на ChatGPT могла открыть доступ к чужим чатам?
Ссылка