В Docker Engine 29.8.2 разработчики собрали крупный пакет исправлений безопасности: три уязвимости затрагивают сам Engine, ещё десять — BuildKit. Самые чувствительные сценарии связаны с подменой образов через вредоносный DNS-ответ, перегрузкой хоста при загрузке специально подготовленного OCI-индекса и атаками на зашифрованные overlay-сети Swarm. Параллельно обновлены BuildKit 0.33.1, containerd 2.3.6 и runc 1.5.2.
Docker Engine 29.8.2 объединяет 13 security-исправлений
У патчевого релиза 29.8.2 получился необычно плотный список исправлений безопасности. В официальных release notes Docker перечислены три уязвимости Docker Engine и десять проблем BuildKit. Сам релиз датирован 30 сентября 2026 года, а актуальная документация Docker с описанием версии появилась в свежем цикле обновлений начала октября.
Предыдущая версия 29.8.1 в основном исправляла ошибки в containerd image store, OpenVZ, работе с hard link в Windows и сетевом API. В 29.8.2 акцент сместился на цепочку поставки контейнеров, сетевую безопасность и устойчивость демона к специально подготовленным входным данным.
Почему такой набор заслуживает отдельного внимания? Docker часто оказывается в центре CI/CD, локальной разработки и серверной инфраструктуры одновременно. Уязвимость в одном компоненте может проявиться ещё до запуска контейнера — например, при загрузке образа или обработке Dockerfile.
Вредоносный DNS-ответ мог повлиять на соединение с registry
CVE-2026-92543 затрагивает подключение Docker к registry. Специально сформированный DNS-ответ мог привести к пропуску проверки TLS-сертификата либо к переходу соединения на HTTP.
В таком сценарии появляются два конкретных риска. Первый связан с учётными данными registry: они могут оказаться доступны атакующей стороне. Второй касается содержимого образа — вместо ожидаемого контейнерного образа клиент потенциально мог получить подменённый вариант.
Для инфраструктуры, где образы регулярно подтягиваются из публичных и приватных registry, проблема затрагивает сам момент доставки программного артефакта. Контейнеру ещё не требуется запускаться, чтобы цепочка доверия уже оказалась нарушена.
Специально подготовленный OCI-индекс мог перегрузить CPU и память
CVE-2026-53493 относится к containerd и обработке OCI image index. Атакующий мог создать индекс с очень глубокой вложенностью или большим количеством разветвлений между descriptor-объектами. При загрузке такого образа система начинала рекурсивно обходить структуру без достаточных ограничений по глубине и ширине.
Результат — неконтролируемое потребление процессорного времени и памяти. По данным advisory containerd, проблема возникает во время PullImage, то есть ещё до выполнения контейнера.
Это делает сценарий заметным для серверов сборки и узлов, которые автоматически загружают образы. Вредоносному образу не требуется получить выполнение внутри контейнера: нагрузка создаётся на этапе обработки его метаданных.
В составе Docker Engine 29.8.2 используется containerd 2.3.6. В этой ветке исправление ограничивает обход ссылок и количество обрабатываемых элементов, убирая возможность бесконтрольного разрастания графа OCI-описателей.
Swarm получил исправление для зашифрованных overlay-сетей
CVE-2026-92542 связана с Docker Swarm и encrypted overlay network — виртуальной сетью, которая соединяет контейнеры и сервисы на разных узлах кластера.
До исправления непривилегированный пользователь на одном Swarm-узле мог внедрять поддельные Ethernet-кадры в зашифрованные overlay-сети на других узлах. Такая возможность затрагивает границы сетевой изоляции внутри кластера, особенно если один физический или виртуальный сервер используется несколькими пользователями или сервисами.
Сама уязвимость относится к сетевому уровню. Она не описывается как получение административного доступа к узлу, но даёт атакующему возможность воздействовать на трафик внутри защищённой overlay-инфраструктуры.
BuildKit 0.33.1 закрывает десять отдельных CVE
Самая большая часть security-пакета находится в BuildKit — движке, который Docker использует для современных сборок образов. Docker Engine 29.8.2 обновляет его до версии 0.33.1.
Исправления охватывают сразу несколько классов проблем:
| Область | CVE | Суть проблемы |
| Работа с proxy CA | CVE-2026-93315 | Сборочный шаг мог нарушить очистку proxy CA и воздействовать на путь за пределами корневой файловой системы сборки |
| CDI-устройства | CVE-2026-93316 | Запрос CDI-устройства при отключённой CDI-поддержке мог вызвать panic демона |
| Кэш сборки | CVE-2026-93317 | При containerd image store клиент через низкоуровневый LLB API мог загрязнить кэш данными, содержимое которых не совпадало с заявленным digest |
| Кэш слоёв | CVE-2026-93318 | Специально подготовленный образ мог подменять соответствие между DiffID и реальным содержимым слоя |
| Gateway frontend | CVE-2026-93319 | Внешний frontend мог довести демон до аварийного завершения через некорректные запросы и гонки жизненного цикла |
| Special files | CVE-2026-93320 | Чтение snapshot и операции LLB mkfile небезопасно обрабатывали специальные файлы |
| LLB symlink | CVE-2026-93321 | Некорректные данные владельца symlink в LLB file operation могли вызвать crash |
| LLB merge | CVE-2026-93322 | Несовпадающее число входов в malformed LLB merge могло аварийно завершить демон |
| Размер входных данных | CVE-2026-93323 | Чрезмерно большой Dockerfile, .dockerignore, gateway-файл или вложенный LLB мог исчерпать память демона |
| Git source policy | CVE-2026-93326 | Специально сформированный Git-источник мог обходить правила source policy, сопоставляющие URL репозитория |
Здесь хорошо видна общая тема релиза: BuildKit получает дополнительные границы на входных данных и более строгую проверку соответствия между заявленными метаданными и фактическим содержимым.
Для CI/CD это особенно заметно в проектах, где сборочная система принимает Dockerfile, Git-источники, внешние frontend-компоненты или образы из разных registry. Именно такие входы фигурируют сразу в нескольких CVE из набора 29.8.2.
Отравление build cache затрагивало доверие к результату сборки
CVE-2026-93317 и CVE-2026-93318 выделяются среди остальных проблем BuildKit, потому что связаны с целостностью кэша.
Кэш сборки нужен для ускорения повторных сборок: BuildKit сохраняет промежуточные результаты и использует их, когда входные данные считаются теми же самыми. Если содержимое blob или слоя не соответствует заявленному digest либо DiffID, система может принять некорректные данные за уже проверенный результат.
CVE-2026-93317 затрагивает containerd image store и низкоуровневый LLB API. CVE-2026-93318 связана со слоями вредоносного образа и неверным соответствием DiffID фактическому содержимому.
Для разработчика внешний симптом может выглядеть гораздо менее очевидно, чем обычный crash. Сборка завершается, кэш продолжает работать, но происхождение части данных уже нельзя считать корректно подтверждённым прежним механизмом проверки.
Огромный Dockerfile мог использовать память демона без ограничений
CVE-2026-93323 относится к отказу в обслуживании через размер входных данных. BuildKit мог расходовать чрезмерный объём памяти при обработке слишком большого Dockerfile, .dockerignore, gateway-файла или вложенного LLB-описания.
Сценарий особенно понятен на общих build-серверах: один процесс сборки способен повлиять на доступность демона для остальных задач. При высокой автоматизации проблема могла проявляться как неожиданное завершение build worker или резкое давление на память хоста.
В 0.33.1 обработка таких структур получила ограничения, которые не позволяют бесконтрольно увеличивать потребление памяти на этом пути.
Git source policy получила более строгую проверку источника
CVE-2026-93326 затрагивает механизм source policy в BuildKit. Эти правила могут использоваться для ограничения источников, из которых разрешено брать код во время сборки.
Проблема позволяла сформировать Git-источник так, чтобы locator bundle-файла или полный remote URL не совпадал с идентификатором, по которому применялось правило. В результате реальный источник мог пройти мимо ожидаемой проверки URL.
Для инфраструктуры, где разрешён ограниченный набор Git-репозиториев, такой разрыв между проверяемым идентификатором и фактическим remote URL напрямую связан с контролем происхождения исходного кода.
docker cp снова работает с вложенными bind mount и socket
За пределами security-блока релиз содержит два исправления обычных ошибок.
Первое касается docker cp. Команда могла завершаться с ошибкой, если в контейнере находился bind-mounted socket, вложенный внутрь другого bind mount. Такие конфигурации встречаются, например, когда контейнеру передают Unix socket из хоста вместе с более крупным смонтированным каталогом.
Docker 29.8.2 исправляет этот сценарий, поэтому docker cp снова может работать с такой структурой mount-точек.
docker info больше не падает на custom default address pools после reload
Второе исправление относится к сетевой конфигурации демона. После reload Docker с пользовательскими default-address-pools команда docker info могла завершаться ошибкой invalid Prefix.
Проблема проявлялась именно после перезагрузки конфигурации демона и была связана с обработкой сетевых префиксов. В 29.8.2 этот путь исправлен, поэтому информация о Docker Engine снова формируется корректно при кастомных пулах адресов.
Docker обновил BuildKit, containerd и runc в одном патчевом релизе
Вместе с исправлениями Docker Engine 29.8.2 обновляет три ключевых компонента контейнерного стека:
- BuildKit 0.33.1 — включает десять security-исправлений, перечисленных в release notes;
- containerd 2.3.6 — содержит исправление CVE-2026-53493 для OCI image index;
- runc 1.5.2 — актуальный patch-релиз runtime, включённый в статические бинарные сборки Docker.
Для сравнения, Docker Engine 29.8.1 был сосредоточен на исправлениях совместимости и поведения отдельных функций. Версия 29.8.2 собрала изменения, которые проходят через сразу несколько уровней контейнерного стека: загрузку образов, registry-соединения, Swarm networking, BuildKit cache, LLB, Git-источники и runtime-компоненты.
После 29.8.1 фокус ветки 29.8 сместился к безопасности
Docker Engine 29.8.2 выглядит как патчевый релиз по номеру версии, но объём security-изменений получился заметным: три CVE относятся к Docker Engine и containerd, ещё десять — к BuildKit. При этом часть исправлений затрагивает этапы, которые происходят до запуска контейнера: загрузку образа, проверку registry, обработку Dockerfile и работу build cache.
Ветка 29.8 теперь закрывает сразу несколько классов атак — от ресурсного истощения до подмены данных в цепочке сборки и воздействия на Swarm overlay network. Одновременно 1 октября в репозитории Moby уже появился 29.9.0-rc.1, поэтому развитие следующей ветки идёт параллельно с выпуском security-патчей для 29.8.
Дальнейшая картина будет зависеть от того, какие из этих уязвимостей окажутся практически эксплуатируемыми в реальных CI/CD и многопользовательских Docker-средах и появятся ли дополнительные уточнения в advisory разработчиков.
