Docker Engine 29.9.3 стал стабильным 3 ноября 2026 года и несёт самый крупный security-батч линии 29.9.x: четыре CVE в движке и SwarmKit плюс два адвайзори BuildKit.[1][2] Если вы следили за историей безопасности 29.x, вы уже знаете: эта линия регулярно получала фиксы с 29.9.0 от 8 октября - и именно 29.9.3 та версия, на которую стоит перейти сегодня.[1] Этот материал перерабатывает нашу прошлую заметку про 29.9.0 в полную историю линии и даёт практический путь апгрейда с 29.9.0 на 29.9.3 на self-hosted Debian/Ubuntu VPS, с двумя местами, которые заслуживают особого внимания: firewalld плюс зашифрованные Swarm overlay, и ротация worker/manager TLS-сертификатов.[2]

Если вы ещё выбираете, где жить хостингу, - сравнение digitalocean vs linode vs vultr покрывает выбор облака начального уровня. Этот апгрейд про версии, поэтому дистрибутив важнее провайдера.

Линия 29.9.x в двух словах

Прежде чем нырнуть в 29.9.3, вот что выходило в линии, потому что правильный путь апгрейда зависит от того, где вы начали.[1][2][9][11][12]

  • 29.9.0 (8 октября 2026) - security-релиз, построенный вокруг Go-тулчейна. Он поднял Go runtime до 1.26.9 и закрыл пять CVE, из них четыре удалённых HTTP/2 denial-of-service (крах демона через HPACK-энкодер, исчерпание памяти через Trailer-заголовки, обход flow-control через сброс потоков и исчерпание CPU через смену window size), плюс один Windows-only джанкшн-эскейп. Также добавил lazy-pull в containerd image store и батч настоящих фиксов зашифрованных overlay-сетей и IPsec.
  • 29.9.1 (14 октября 2026) - релиз, ведомый containerd. Он принёс containerd v2.4.2, который закрыл три проблемы при pull образов: CVE-2026-95839, GHSA-8647-2jxj-p2rc и GHSA-hc94-p972-ch66.[9]
  • 29.9.2 (20 октября 2026) - релиз про Go runtime. Он обновил Go runtime до 1.26.10, чтобы закрыть CVE-2026-111943: отклонение цепочек сертификатов через восемь отозванных промежуточных TLS-сертификатов eMudhra. Pull и push в любой registry, чья цепочка опирается на эти промежуточные, теперь падают на проверке TLS.[11]
  • 29.9.3 (3 ноября 2026) - кумулятивный security-батч: два CVE движка, один CVE Swarm overlay, один CVE SwarmKit, два адвайзори BuildKit, плюс багфиксы зависания демона и YAML-ключей в CLI.[1][2]

Если вы всё ещё на 29.8.x или на линии 28.x - к вам относится всё вышеперечисленное, потому что батч 29.8.2, фиксы 29.8.x и вся последовательность 29.9.x подтягиваются к моменту, когда вы дошли до 29.9.3.

Что закрывает 29.9.3

Батч 29.9.3 делится между движком, SwarmKit и встроенным билдером BuildKit.[1][2]

Чрезмерное потребление CPU при парсинге crafted RSA-ключей (CVE-2026-116587, GHSA-mgcc-cww5-fp2q). Crafted RSA-ключ мог вызвать чрезмерную нагрузку на CPU при разборе его движком.[1][3] Для деплой-хоста практическая форма - denial-of-service: вход, которым вы не владеете и который контролируете, при разборе может прижать демон. Исправлено в 29.9.3.

Паника при декомпрессии zstd (CVE-2026-116591, GHSA-fpmh-frq8-7rj8). Crafted zstd-поток может вызвать панику при декомпрессии его движком.[1][4] Паника демона - это удар по доступности: демон может упасть, унося с собой управление вашими ворклоадами (контейнеры продолжают работать, но вы теряете возможность ими управлять, пока демон не вернулся). Исправлено в 29.9.3.

Swarm overlay теряет шифрование и защиту от спуфинга после flush firewalld (CVE-2026-115538, GHSA-6jhp-7446-hf7f). Это тот фикс, который стоит держать в центре внимания, если на хосте работает firewalld - а это по умолчанию на Fedora, RHEL-семействе и на любом VPS-образе, стартующем с активным firewalld. Когда firewalld сфлашивает iptables-правила Docker, защиты encrypted overlay падают - пропадают те самые гарантии шифрования и аутентичности, которые вы ожидали.[1][5] Классический триггер - firewall-cmd --reload или любой несвязанный перезагруз ruleset, который вычищает Docker-управляемые цепочки; после этого overlay-трафик теряет гарантии конфиденциальности/аутентичности. На self-hosted VPS это ровно тот режим отказа «мой encrypted overlay молча стал нешифрованным», который трудно заметить, пока не проверишь ruleset. Исправлено в 29.9.3.

Worker может получить manager-сертификат вскоре после смены лидера Swarm (CVE-2026-115539, GHSA-628g-hv7f-pgjc, SwarmKit). Атакующий с валидным worker-нодовым TLS-сертификатом и приватным ключом мог получить manager-сертификат вскоре после смены лидера Swarm.[1][6] Эскалация важна, потому что manager-сертификат позволяет выпускать сертификаты и менять состояние кластера, а не только запускать задачи. Это аргумент относиться к воркер-креденшелам как к чувствительным и ротировать их на любой ноде, в которой вы сомневаетесь, - и апгрейдить все ноды, а не только менеджеры, потому что SwarmKit живёт и на воркерах. Исправлено через апдейт SwarmKit в 29.9.3.

BuildKit v0.34.2 закрывает два адвайзори. Встроенный билдер (по умолчанию в buildx) обновляется до v0.34.2, который исправляет:

  • GHSA-2fqp-xg6f-v7gj - отравление resolver-кэша / крах демона. Сборка, разрешающая метаданные одного и того же Git-референса дважды, может уронить демон BuildKit через отравление resolver-кэша.[1][7] Это крах, так что угол доступности актуален везде, где вы гоняете недоверенные сборки.
  • GHSA-w26x-xg27-7qjc - эскейп через xattr. Вредоносный клиент с доступом к BuildKit control API мог выставлять extended attributes на файлы за пределами state-директории BuildKit - потенциально в скоупе trusted. или security., что может дать программе на хосте больше привилегий, чем у неё есть самой.[1][8] Адвайзори отмечает: это релевантно, только если вы гоняете build-сервис, принимающий сборки от недоверенных пользователей, но если на машине CI или общий build-эндпоинт - патчите и не экспонируйте BuildKit control API в сеть.[8]

Багфиксы, о которых стоит знать. 29.9.3 также чинит зависание демона на container, image и system API-запросах под нагрузкой (moby/moby#54041) и буквальные ключи << в YAML-файлах, эмитящиеся без кавычек (docker/cli#7461).[1][2] Первый - реальная заноза для self-hosting: под нагрузкой движок мог стопорить обычные API-вызовы; второй убирает грабли с <<-анкерами при перечитывании конфигов.

Почему релизы Go-runtime - это security-релизы

29.9.0 и 29.9.2 - security-релизы, построенные на Go-тулчейне, и механизм стоит напомнить, потому что он объясняет, почему «runtime»-бамп - это вообще security-релиз.[1][11][12]

Движок написан на Go, и Docker вшивает конкретный тулчейн Go в каждую сборку. Когда батч уязвимостей приходит в стандартную библиотеку Go, фикс доезжает до вашего демона как перекомпиляция на пропатченном Go, а не как патч движка. Это ровно четыре HTTP/2 CVE 29.9.0 (CVE-2026-97032 крах, 78659 память, 78663 flow-control, 78669 CPU) - все достижимы от пира, говорящего с вашим демоном по HTTP/2, чем являются и Engine API, и gRPC-frontend BuildKit, - и отклонение цепочек через скомпрометированные промежуточные eMudhra в 29.9.2 (CVE-2026-111943, через Go 1.26.10).[1][11][12] Поскольку эти фиксы едут на тулчейне, вы не увидите их в выводе компонентов docker version; поле Server.Version - ваш единственный надёжный сигнал, что вы на перекомпилированном движке. Изменения Go-runtime кумулятивны, так что вы получаете все (включая фиксы 1.26.9) просто дойдя до 29.9.3.

Чек-лист апгрейда 29.9.0 -> 29.9.3 для VPS

Конкретный путь на self-hosted Debian/Ubuntu хосте с двумя зонами, требующими осознанного внимания.

1. Уточните текущую версию.

docker version --format '{{.Server.Version}}'   # версия самого движка, а не CLI
docker info | grep -i "Server Version"

Если там 29.9.3 - вы закончили. Если вы на 29.9.0, 29.9.1 или 29.9.2 - всё ниже по-прежнему к вам относится. Если вы на 29.8.x или старше - вы пропускаете всё вышеперечисленное. Как бы вы ни обновлялись из apt-репозитория Docker на Debian/Ubuntu:

# окно обслуживания - это перезапустит демон и ваши контейнеры
sudo apt-get update
sudo apt-get install --only-upgrade docker-ce docker-ce-cli containerd.io

Затем проверка:

docker version --format '{{.Server.Version}}'   # ожидаем 29.9.3
docker buildx version                           # ожидаем BuildKit v0.34.2+
docker ps                                       # все ворклоады подняты с корректным состоянием

Обратите внимание: --only-upgrade подтягивает всю цепочку - containerd.io (до v2.4.2) и бандл buildx (BuildKit до v0.34.2) приходят вместе с движком, так что одна команда достигает кумулятивного набора фиксов.

2. Firewalld + зашифрованный Swarm overlay: аудит и повторная проверка шифрования.

Поскольку CVE-2026-115538 запускается flush от firewalld iptables-правил Docker, любой firewall-cmd --reload или изменение ruleset - повод убедиться после апгрейда, что overlay снова реально зашифрован.[1][5] После перехода на 29.9.3 чисто переинициализируйте зашифрованные сети. Конкретно, на каждой ноде кластера:

# проверяем, что docker zone и состояние overlay выглядят правильно
sudo firewall-cmd --get-zones | grep docker
sudo iptables -t nat -L -n | grep -i docker   # Docker-управляемые правила на месте
docker network ls --filter driver=overlay

На swarm с --opt encrypted пересоздайте или редеплойте сервисы, чтобы правила шифрования data-plane перепрограммировал уже исправленный движок, и выборочно проверьте, что overlay-трафик между нодами больше не едет незащищённым. Если ваша автоматизация перезагружает firewalld на любое событие - добавьте это в post-reload чек-лист: это ровно класс инцидента, который описывает данная CVE.

3. Ротируйте worker и manager TLS-сертификаты.

CVE-2026-115539 (worker может получить manager-сертификат вскоре после смены лидера) означает, что воркер-креденшелы - это граница доверия, а не токен, которым можно пренебречь.[6] После апгрейда всех нод ротируйте сертификаты на любой ноде, чей ключ вы не доверяете; пересоздание всего CA-материала кластера для большинства хомлэбов избыточно - достаточно прицельной ротации:

# на менеджере - политика экспайри сертификатов ноды
docker node update --cert-expiry 2160h <node>
# на самой ноде - обновление своей пары сертификатов
sudo systemctl restart docker
docker node ls                                   # все ноды Ready/Reachable

В single-manager хомлэбе окно узкое, но поведение зафиксируйте: апгрейдите все ноды в одном окне обслуживания (и менеджеры, и воркеры), потому что SwarmKit живёт и на воркерах, и фикс вступает в силу только когда заплатена каждая нода.[1][6]

4. Перезапускайте по одной ноде и пините прошлую версию.

Поскольку апгрейд каждой ноды перезапускает демон и перенегоциирует состояние overlay, прокатывайте по одной ноде и давайте сервисам устаканиться до перехода к следующей. Запините прошлую версию движка в автоматизации, чтобы неудавшийся апгрейд откатывался быстро, и сначала протестируйте на стейджинг-хосте, если используете кастомные daemon-флаги, необычные снапшоттеры или сильно кастомизированный iptables-ruleset - взаимодействия с firewalld именно то место, где этот релиз больно кусается.

Обновляйтесь сейчас, если…

Пройдитесь по списку и обновляйтесь, если:

  • вы используете зашифрованные overlay-сети Swarm и firewalld в картине есть (или может быть) - CVE-2026-115538 целится прямо в режим отказа «flush, а потом потеряли шифрование»;[5]
  • worker TLS-ключ какой-то ноды - не то, чему вы доверяете полностью: CVE-2026-115539 превращает валидный worker-ключ в manager-сертификат после смены лидера;[6]
  • вы гоняете любой build-сервис, принимающий сборки от недоверенных пользователей - оба адвайзори BuildKit релевантны, и xattr-эскейп может дотянуться до привилегий хоста;[7][8]
  • ваш Engine API или сервис на его основе достижим по сети чем-то, чему вы не доверяете полностью - четыре HTTP/2 и DoS-классы RSA/zstd - всё это категории «доступный вход»;[1]
  • вы тянете из или пушите в registry, чья TLS-цепочка может касаться отозванных промежуточных eMudhra - эта проверка живёт только в 29.9.2+.[11]

Обновляйтесь при удобном случае, а не срочно, если вы одиночный неэкспонированный в сеть хост без зашифрованных overlay, без build-эндпоинта и с полностью доверенными локальными креденшелами - кумулятивные фиксы Go-runtime и пул-пути всё равно стоит взять, но ваша экспозиция к именно этому батчу узкая.

Источники

  1. Docker - Engine 29 release notes (29.9.3, 2026-11-03: CVE-2026-116587, CVE-2026-116591, CVE-2026-115538, SwarmKit CVE-2026-115539, адвайзори BuildKit v0.34.2, moby#54041 зависание демона, cli#7461 YAML-ключи <<). https://docs.docker.com/engine/release-notes/29/ - checked 2026-11-05
  2. GitHub - релиз moby/moby docker-v29.9.3 (опубликовано 2026-11-03). https://github.com/moby/moby/releases/tag/docker-v29.9.3 - checked 2026-11-05
  3. GitHub - GitHub Advisory GHSA-mgcc-cww5-fp2q (CVE-2026-116587, чрезмерное потребление CPU при парсинге crafted RSA-ключей). https://github.com/advisories/GHSA-mgcc-cww5-fp2q - checked 2026-11-05
  4. GitHub - GitHub Advisory GHSA-fpmh-frq8-7rj8 (CVE-2026-116591, паника при декомпрессии zstd). https://github.com/advisories/GHSA-fpmh-frq8-7rj8 - checked 2026-11-05
  5. GitHub - релиз moby/moby docker-v29.9.3 (CVE-2026-115538, потеря шифрования/спуфинг-защит Swarm overlay после flush firewalld iptables-правил Docker; адвайзори Swarm overlay GHSA-6jhp-7446-hf7f). https://github.com/moby/moby/releases/tag/docker-v29.9.3 - checked 2026-11-05
  6. GitHub - релиз moby/moby docker-v29.9.3 (CVE-2026-115539, worker TLS-сертификат может получить manager-сертификат вскоре после смены лидера Swarm; адвайзори SwarmKit GHSA-628g-hv7f-pgjc). https://github.com/moby/moby/releases/tag/docker-v29.9.3 - checked 2026-11-05
  7. GitHub - security advisory moby/buildkit GHSA-2fqp-xg6f-v7gj (отравление resolver-кэша, крах демона; исправлено v0.34.2). https://github.com/moby/buildkit/security/advisories/GHSA-2fqp-xg6f-v7gj - checked 2026-11-05
  8. GitHub - security advisory moby/buildkit GHSA-w26x-xg27-7qjc (xattr выставляется за пределами state-директории BuildKit, возможная эскалация привилегий на хосте). https://github.com/moby/buildkit/security/advisories/GHSA-w26x-xg27-7qjc - checked 2026-11-05
  9. GitHub - релиз moby/moby docker-v29.9.1 (опубликовано 2026-10-14; containerd v2.4.2: CVE-2026-95839, GHSA-8647-2jxj-p2rc, GHSA-hc94-p972-ch66). https://github.com/moby/moby/releases/tag/docker-v29.9.1 - checked 2026-11-05
  10. GitHub - security advisory containerd GHSA-8647-2jxj-p2rc (крах демона с crafted Content-Length при параллельной выкачке слоёв через concurrent_layer_fetch_buffer; исправлено 2.4.2). https://github.com/containerd/containerd/security/advisories/GHSA-8647-2jxj-p2rc - checked 2026-11-05
  11. GitHub - релиз moby/moby docker-v29.9.2 (опубликовано 2026-10-20; Go runtime 1.26.10, CVE-2026-111943 отозванные промежуточные TLS eMudhra). https://github.com/moby/moby/releases/tag/docker-v29.9.2 - checked 2026-11-05
  12. GitHub - релиз moby/moby docker-v29.9.0 (опубликовано 2026-10-08; Go runtime 1.26.9, четыре HTTP/2 CVE плюс Windows-джанкшн-эскейп, lazy-pull, сетевые фиксы). https://github.com/moby/moby/releases/tag/docker-v29.9.0 - checked 2026-11-05
  13. golang/go - issue #82345 для CVE-2026-111943 (денлист восьми скомпрометированных SPKI eMudhra в crypto/x509, исправлено Go 1.26.10 / 1.27.3). https://go.dev/issue/82345 - checked 2026-11-05