Исследователи Imperva Red Team обнаружили уязвимость CVE-2026-17106 в команде docker cp, которая позволяет вредоносному контейнеру или песочнице перезаписывать файлы на хосте за пределами директории, указанной пользователем. В зависимости от прав, с которыми запущена команда, это может привести к выполнению произвольного кода от имени пользователя или даже к получению root-доступа на Linux-системах. Разработчики Docker выпустили исправления, закрывающие проблему в Docker Engine, CLI, Desktop и Sandboxes.
Уязвимость CVE-2026-17106
Проблема кроется в самом процессе копирования. Когда пользователь выполняет docker cp для извлечения файла из контейнера, Docker daemon упаковывает содержимое в архив, а CLI на стороне клиента распаковывает его в выбранную директорию. Контейнер контролирует содержимое этого архива, а распаковка происходит с правами пользователя, запустившего команду. Если злоумышленник управляет контейнером, он может подготовить архив таким образом, чтобы при извлечении запись произошла не в указанное место, а в произвольный путь на хосте.
Для этого используются две взаимосвязанные слабости. Первая связана с формированием архива: пока daemon обходит файловую систему работающего контейнера, процессы внутри него могут изменять структуру каталогов, например, подменять директории символическими ссылками. В результате архив оказывается несогласованным: в нём присутствует запись о символической ссылке, ведущей за пределы целевой директории, и запись о файле, который якобы находится внутри этой ссылки. Вторая слабость относится к процедуре извлечения: Docker CLI проверяет один путь, а создаёт другой. Проверка безопасности пытается убедиться, что извлекаемый объект не выходит за границы назначения, но из-за ошибки в расчёте путей она пропускает опасную последовательность. В итоге ядро операционной системы создаёт файл там, куда указывает символическая ссылка, игнорируя задуманное ограничение.
Практическая эксплуатация выглядит так. Пользователь запускает docker cp, чтобы забрать из контейнера логи, артефакты сборки или результаты тестов. Контейнер тем временем подменяет нужный каталог ссылкой на критичный файл хоста. После распаковки на месте этого файла оказывается содержимое из архива. Атакующий может перезаписать shell-конфигурацию, исполняемые файлы, SSH-ключи или механизмы автозагрузки. На macOS достаточно подменить скрипт запуска терминала, чтобы код злоумышленника выполнился при следующем входе пользователя в систему. На Linux, если команда запущена с повышенными привилегиями через sudo, можно заменить системный бинарный файл, отвечающий за запуск контейнеров, и получить root-доступ сразу после завершения копирования.
Исследователи подтвердили работоспособность атаки на Linux с Docker Engine 29.6.1 и на macOS с Docker Desktop 4.81.0. Они также отметили, что уязвимость затрагивает Docker Sandboxes - решение для изолированного запуска ИИ-агентов. В нём аналогичная команда sbx cp используется для перемещения файлов между песочницей и хостом. Если агент в песочнице скомпрометирован, извлечение созданного им артефакта может привести к записи за пределы целевой директории. Docker подтвердил, что CVE-2026-17106 распространяется и на sbx cp, и выпустил исправление в версии Sandboxes 0.38.0.
Особую опасность уязвимость представляет для автоматизированных сред. В CI-системах docker cp часто выполняется с правами root для сбора артефактов или логов. При обработке кода из недоверенных источников контейнер, участвующий в сборке, может содержать вредоносные модификации. Аналогичная ситуация возникает при реагировании на инциденты: специалист по безопасности копирует улики из уже скомпрометированного контейнера, и именно эта операция становится триггером для атаки на хост.
Временные меры защиты включают отказ от копирования из работающих контейнеров без необходимости. Остановка контейнера перед извлечением файлов предотвращает гонку, лежащую в основе атаки. Если контейнер подозрителен, данные из него следует забирать в изолированной среде или с использованием учётной записи с минимальными правами. Крайне не рекомендуется запускать docker cp через sudo или в сценариях автоматизации с root-доступом.
Разработчики Docker устранили уязвимость в нескольких релизах. Исправление для moby/go-archive, библиотеки, отвечающей за создание и распаковку архивов, вышло 30 июля 2026 года в версии v0.3.0. Docker Engine и CLI 29.7.0 получили соответствующее обновление, однако оно вызвало регрессии в работе, поэтому потребовались дополнительные выпуски. Полное исправление закреплено в Docker Engine и CLI 29.7.2. Пользователям Docker Desktop доступна версия 4.86.0, вышедшая 10 августа 2026 года, которая включает исправленную версию Engine и корректную обработку символьных ссылок на стороне клиента. Владельцам Docker Sandboxes следует обновиться до версии 0.38.0, вышедшей 6 августа.
Уязвимость демонстрирует, что граница безопасности контейнера не ограничивается изоляцией процессов и файловой системы. Инструменты, переносящие данные между контейнером и хостом, сами становятся частью этой границы. Пока распаковка архивов выполняется с привилегиями пользователя и доверяет структуре архива, остаётся риск выхода за пределы целевой директории. Исправления Docker ужесточают проверку символических ссылок при извлечении, но пользователям важно обновить все компоненты Docker, включая CLI, Engine и Desktop, чтобы закрыть путь атаки во всех сценариях использования.
Ссылки
