Зловреден код, изпълняван във виртуална машина на Docker Sandboxes под macOS, би могъл да излезе извън споделената проектна директория и да чете или променя файлове навсякъде върху хост системата, предупреждава Docker в съобщение за сигурност от 15 септември.
Ескейпът се изпълнява с правата на хост профила, който стартира виртуалната машина. Уязвимостта CVE-2026-77179 е оценена като критична (Critical), засяга версии от 0.28.0 до 0.42.0 (без да включва 0.42.0) под macOS и е отстранена във версия 0.42.0 на 7 септември.
Docker Sandboxes стартира всеки AI агент за кодиране в негова собствена малка изолирана среда (виртуална машина) със споделена проектна директория. Кодът, който би могъл да я напусне, е всичко, което се изпълнява вътре във виртуалната машина — като например агент за кодиране, който е бил обърнат срещу своя потребител, или всяко злонамерено съдържание, което агентът инсталира и стартира.
Docker не съобщава за активни експлоатации. Допълнителната оценка на CISA в досието на CVE посочва липса на експлоатация, а уязвимостта не присъства в каталога Known Exploited Vulnerabilities на CISA към версията от 16 септември.
За да се реализира атаката, е необходим зловреден код вътре в изолираната среда, а предпазването на хоста от стартираното от агента съдържание е именно основната цел на тази среда. Агентът инсталира пакети и изпълнява команди със sudo във виртуалната машина, а документацията за изолация на Docker отбелязва, разграничението през хипервизора е „основната защита за изолация, а не разделянето на привилегии вътре във виртуалната машина“.
Ескейпът преминава през хост сървъра virtio-fs — хост страната на файловото споделяне между Mac и виртуалната машина, която е проследявала символни връзки (symlinks) при повторно отваряне на премахнат файл от съхранен път, съобщават от Docker.
Гост системата (всичко, което се изпълнява във виртуалната машина) би могла да замени родителска директория със символна връзка и след това да чете или променя файлове като потребителя на VMM (профилът на хоста, под който работи мониторът на виртуалната машина), което според Docker „потенциално води до изпълнение на код на хост системата“.
От март насам документацията на Docker посочва, че символни връзки, сочещи извън работното пространство (терминът на Docker за споделената проектна директория), не се проследяват.
Също така, същата версия отстранява и втора уязвимост — CVE-2026-79994, оценена от Docker като висока (High) с CVSS оценка 8.7, в релето, което позволява на изолираната среда да се свързва с Unix domain сокети в рамките на нейното оторизирано работно пространство.
Релето проверява дали пътят до сокета е вътре в работното пространство, след което се свързва повторно чрез името на пътя. Злонамерен субект в гост системата, който замени директория по този път със символна връзка между проверката и свързването, би могъл да накара хоста да се свърже с всеки AF_UNIX сокет извън работното пространство, което според Docker „излага на риск данни или възможности на хоста, предоставяни от този сокет“.
Тази уязвимост засяга версии от 0.37.0 до 0.41.9, но не и 0.42.0. Docker посочва първата уязвимост като специфична само за macOS, но не посочва платформа за втората, при положение че Docker Sandboxes работи върху macOS, Windows и Linux хостове. Оценката на CISA също посочва липса на известна експлоатация и уязвимостта не присъства в KEV каталога.
Засегнати версии и какво да инсталирате
| CVE | Компонент | Засегнати версии | Платформа | Оценка на Docker |
|---|---|---|---|---|
| CVE-2026-77179 | virtio-fs host server | 0.28.0 до (но без) 0.42.0 | macOS | Critical, CVSS 9.4 |
| CVE-2026-79994 | Guest-to-host Unix socket relay | 0.37.0 до (но без) 0.42.0 | Не е посочена | High, CVSS 8.7 |
- Обновете до версия 0.42.0 или по-нова. Към 17 септември най-новата налична версия е 0.43.0, публикувана на 15 септември.
- Ако все още не можете да инсталирате корекции за сигурност, използвайте режим clone mode и избягвайте добавянето на хост монтирания с права за четене и запис. Това е препоръката на Docker и за двете уязвимости.
По подразбиране sbx run споделя текущата директория в изолираната среда с права за четене и запис. Режимът clone mode работи само когато проектът е Git хранилище и се задава при създаването на изолираната среда, така че съществуваща среда трябва да бъде премахната и създадена отново с флаг --clone.
Режимът clone mode предпазва хранилището от промени, но не и от четене. Хранилището се монтира само за четене в /run/sandbox/source, а непроследяваните файлове като .env остават достъпни за четене вътре в изолираната среда, се посочва в документацията на Docker.
Docker публикува досиетата за CVE и бюлетина за сигурност на 15 септември, осем дни след пускането на версия 0.42.0.
Бележките към версия 0.42.0 в GitHub и в сайта с документация на Docker не споменават конкретно нито един от двата CVE идентификатора към 17 септември. Сред рутинните корекции се съобщава за отстраняване на проблем, при който „изолиран процес би могъл да накара демона да отвори хост D-Bus транспорт и да изпълни произволна команда на хоста“. Docker не е свързал официално тази корекция с някой от посочените CVE номерa.
Досието за 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 описаха как AI агент за кодиране под въздействието на prompt injection вътре в базирана на Docker изолирана среда може да бъде подведен да експлоатира отделна уязвимост в Docker Engine срещу хост системата.