Docker Engine 29.9.0 — устранены уязвимости HTTP/2 и риск передачи открытого трафика в Swarm

8 октября 2026 года вышел Docker Engine 29.9.0. Обновление закрывает пять уязвимостей, связанных с библиотеками Go, исправляет ошибку в зашифрованных overlay-сетях Docker Swarm и меняет работу с контейнерными образами в хранилище containerd. Наибольшее значение эти изменения имеют для серверов с доступным Docker API, кластеров Swarm и систем, которые скачивают и повторно публикуют образы.

Docker Engine — устранены уязвимости HTTP/2

Уязвимости HTTP/2 могли приводить к сбою или перегрузке Docker Engine

В Docker Engine 29.9.0 обновили среду Go до версии 1.26.9 и библиотеку golang.org/x/net до 0.60.0. В совокупности они закрывают четыре ошибки обработки HTTP/2, перечисленные в официальных примечаниях к выпуску. HTTP/2 — протокол передачи запросов, а dockerd — фоновый процесс, который управляет контейнерами и принимает обращения через Docker API.

Особенно показателен случай CVE-2026-97032. Клиент мог многократно изменять размер таблицы заголовков HPACK в HTTP/2. В прежней реализации Go одновременная работа с кодировщиком заголовков могла завершиться аварийным падением сервера. В разборе разработчиков Go объясняется причина: две параллельные операции обращались к одному состоянию без необходимой синхронизации.

Остальные три проблемы затрагивали доступность сервиса по другим направлениям:

CVE-2026-78659 — большое число полей в заголовке Trailer могло обойти ограничение размера заголовков и исчерпать память демона.
CVE-2026-78663 — последовательный сброс HTTP/2-потоков позволял обойти ограничение управления потоком и заставить сервер буферизовать больше данных, чем предполагалось.
CVE-2026-78669 — создание большого числа потоков с постоянным изменением начального размера окна могло вызвать чрезмерную нагрузку на процессор.

Пятая уязвимость, CVE-2026-56857, относится к Windows. Если у пользователя уже был доступ на запись в каталог данных Docker, он мог разместить там junction — специальную ссылку на другой каталог. Из-за этого демон мог создать директорию за пределами собственного хранилища данных. Для такого сценария требовались локальные права на изменение каталога данных.

В документации Docker отдельно указано, что обновлённая библиотека x/net устраняет аналогичные проблемы в устаревшем эндпоинте /grpc и gRPC-сервере BuildKit, который обслуживает внешние frontend-компоненты сборки, например указанные директивой # syntax= в Dockerfile.

Эти сценарии требуют возможности отправлять соответствующие запросы уязвимому компоненту. Из наличия CVE не следует, что любой контейнер или любой сервер с Docker автоматически доступен для такой атаки извне: значение имеют конфигурация, доступность интерфейсов и используемые компоненты.

Ошибка IPsec в Docker Swarm допускала передачу части пакетов без шифрования

Отдельное исправление Docker Engine 29.9.0 касается зашифрованных overlay-сетей Swarm. Они связывают контейнеры на разных узлах кластера, а IPsec защищает передаваемые между узлами данные. Разработчики обнаружили ошибку в подсчёте ссылок на общие IPsec-туннели.

При добавлении и удалении сетевых соседей внутренний счётчик в некоторых ситуациях расходился с реальным числом использующих туннель соединений. Если создание записи соседа завершалось ошибкой, её последующее удаление могло ошибочно уменьшить счётчик. В результате Docker мог удалить параметры шифрования, пока действующий сетевой endpoint продолжал использовать туннель. Исходящие VXLAN-пакеты тогда могли попадать в сеть открытым текстом.

Масштаб этого сценария ограничен. Согласно описанию исправления, принимающий узел отбрасывает незашифрованные пакеты как поддельные. Поэтому речь идёт преимущественно об односторонней передаче, например UDP-запросах DNS, и попытках установить соединение, которые не завершаются, — таких как TCP SYN. Нормальный двусторонний обмен по защищённому каналу в таком состоянии не устанавливается.

В 29.9.0 Docker согласовал порядок создания и удаления сетевых записей с учётом ссылок на IPsec-туннели. Он также освобождает связанные с ними правила и состояния IPsec после выхода последнего контейнера из зашифрованной overlay-сети. Прежде такие ресурсы могли сохраняться до перезапуска демона. Это объясняет, почему изменение касается одновременно конфиденциальности отдельных пакетов и управления сетевыми ресурсами.

Docker pull получил управление отложенной загрузкой слоёв образов

Ещё одно изменение затрагивает пользователей containerd image store — хранилища контейнерных образов, которое Docker применяет для работы со слоями и их метаданными. Раньше возникала ситуация, когда контейнерный образ удавалось запустить, но не получалось корректно экспортировать или отправить в registry. Причина заключалась в отсутствии нужных файлов слоёв: распакованные данные уже существовали локально, а соответствующие загружаемые blob-объекты отсутствовали.

В Docker Engine 29.9.0 исправлена проверка таких слоёв. Теперь при обычной загрузке недостающие blob-объекты получают из registry, даже если распакованное содержимое слоя уже есть. Это касается, например, нескольких образов с одинаковыми распакованными файлами, но различающимся сжатием слоёв.

Здесь появляется особый случай: удалённые snapshotter-компоненты nydus, overlaybd, soci и stargz рассчитаны на lazy pull, то есть отложенную загрузку содержимого по мере необходимости. Принудительное скачивание всех слоёв лишило бы их этого преимущества. Поэтому разработчики добавили настройку демона lazy-pull, управляющую таким поведением. Для перечисленных remote snapshotter она включена по умолчанию.

В обсуждении исправления отдельно зафиксирован компромисс: образ, загруженный отложенно, может не содержать всех blob-объектов на локальной машине. В таком состоянии операции сохранения или отправки образа способны завершиться ошибкой. Для систем, в которых контейнер сначала запускают через remote snapshotter, а затем экспортируют или публикуют тот же образ, это заметное различие в поведении.

Исправления сетей и rootless-режима затрагивают работу Docker в кластерах

Docker Engine 29.9.0 устраняет несколько проблем, которые проявлялись в конкретных конфигурациях. В Swarm исправлена ситуация, когда узел после перезапуска демона выпадал из обнаружения сервисов и балансировки нагрузки до повторного присоединения к gossip-кластеру. Ещё одна ошибка делала overlay-узлы недоступными после повторного подключения узла или пересоздания сервиса, если VXLAN-интерфейс уже запомнил динамическую запись о соседнем узле.

Для сетей с режимом routed gateway исправлено отображение опубликованных портов в docker ps и ответе API GET /containers/json. Раньше эти интерфейсы могли пропускать сведения о портах, хотя настройки публикации уже существовали. В сети bridge с отключённым межконтейнерным взаимодействием исправлена доступность опубликованного порта из другого контейнера; отдельно скорректирована работа IPv6 Neighbor Discovery.

В rootless-режиме, когда Docker работает без полномочий root, закрыта утечка соединений к сокету RootlessKit API при каждом запросе GET /version. Кроме того, обновлён сам RootlessKit до 3.2.0. Для администраторов Windows-систем исправлена очистка регистрации Docker как службы: повторная отмена регистрации теперь обрабатывается корректно.

Вместе с Docker Engine обновились BuildKit и containerd

Релиз объединяет изменения нескольких компонентов контейнерного стека:

Компонент	Версия в Docker Engine 29.9.0	Суть изменения
Go	1.26.9	Исправления безопасности, включая обработку HTTP/2
`golang.org/x/net`	0.60.0	Аналогичные исправления HTTP/2 для gRPC-компонентов
BuildKit	0.34.0	Новая версия механизма сборки образов
containerd	2.4.1	Обновление в составе статических бинарных сборок Docker
RootlessKit	3.2.0	Обновление компонента для rootless-режима

BuildKit 0.34.0 содержит собственные изменения. В частности, встроенный Dockerfile frontend обновлён до 1.28.0, для базы данных BoltDB добавлена необязательная пока операция уплотнения, а в сведениях о происхождении сборки (provenance attestation) теперь указывается целевая платформа.

Предыдущий выпуск Docker Engine 29.8.2 от 30 сентября был сосредоточен на 13 исправлениях безопасности в Engine и BuildKit. Версия 29.9.0 затрагивает другой набор проблем: HTTP/2, обработку IPsec-туннелей, сетевую доступность узлов и полноту загрузки образов. Это позволяет рассматривать релизы отдельно по конкретным сценариям, даже несмотря на близость дат выпуска.

Docker Engine 29.9.0 меняет границы сетевой защиты и обработки образов

В Docker Engine 29.9.0 одновременно устранены причины отказа в обслуживании в компонентах HTTP/2 и исправлен узкий сценарий, при котором ошибочный учёт IPsec-туннелей допускал передачу исходящих пакетов без шифрования. Для containerd image store разработчики уточнили поведение загрузки слоёв, сохранив специальный режим для удалённых snapshotter-компонентов.

Открытой остаётся разница между двумя способами работы с образами: отложенная загрузка экономит передачу данных, но наличие запущенного контейнера само по себе не гарантирует готовность всех его слоёв к экспорту или повторной публикации. Теперь это различие явно отражено в поведении Docker Engine и настройке lazy-pull.