Если вы гоняете Docker на своём VPS, релиз от 30 сентября 2026 - это не рутинный бамп версии. В Docker Engine 29.8.2 вышло 13 security-фиксов: три в самом движке и десять во встроенном BuildKit, включая одну уязвимость высокой серьёзности, которая может отдать атакующему ваши registry-креды или подменить образ, который вы тянете, - и ещё две, которые бьют ровно по той схеме, что используют большинство self-hosted-проектов. Это апгрейд, который стоит сделать на этой неделе, а не в следующем месяце.

Почему этот релиз важен

Docker Engine 29.8.2 вышел 30 сентября 2026 как выделенный security-релиз.[1] Он чинит три уязвимости самого движка и пакет из десяти уязвимостей BuildKit, а также обновляет встроенные containerd (v2.3.6), BuildKit (v0.33.1) и runc (v1.5.2).[1][2]

Три из четырёх «заглавных» проблем - обход доверия к registry, инъекция в overlay-сети Swarm и DoS на pull через containerd - складываются в паттерн, который должен беспокоить всех, кто self-hosting-ит на одной машине: они достижимы через pull непроверенных образов, через DNS на хосте, который вы контролируете не полностью, или через непривилегированного пользователя на Swarm-ноде. Ни для одной не нужно запускать вредоносный контейнер: ущерб происходит на этапе резолва и pull, до того как выполнится что-то ваше.

Та, что ломает цепочку доверия к registry - CVE-2026-92543 (High)

Самая опасная уязвимость релиза - CVE-2026-92543 (GHSA-7cfq-22r6-qp73), оценённая как High с CVSS-баллом 7.6.[3]

Механика важна, потому что она тонкая. Docker Engine считает hostname registry «небезопасным» по DNS-проверке any-match: по умолчанию он вносит диапазоны 127.0.0.0/8 и ::1/128 как небезопасные CIDR, а функция сравнения резолвит все адреса hostname и возвращает «небезопасно», если хоть один попадает в эти диапазоны. Транспорт затем пере-подключается по hostname, а не по адресу, который совпал, - поэтому сфальсифицированный DNS-ответ с одним loopback-адресом и одним внешним IP атакующего отключает TLS-проверку сертификата и включает HTTP-fallback для подключения к registry.[3]

Последствия делают это опасным для деплой-хоста:[3]

  • Креды registry, уходящие в заголовке X-Registry-Auth, могут быть раскрыты контролируемому атакующим хосту с невалидным сертификатом.
  • Доверенный тег образа можно подменить манифестом и слоями атакующего в image store - то есть вы тянете «свой» образ, а получаете отравленный.

Второй исход - то, что должно лишать вас сна, если вы гоняете CI/CD или тянете из приватного registry (Docker Hub сюда входит). В advisory приведены workaround-ы на случай, если обновиться немедленно нельзя: закрепить hostname registry за доверенным не-loopback адресом (надёжный DNS или запись в hosts), ограничить исходящий доступ демона только доверенными registry-эндпоинтами и ссылаться на критические образы по digest, а не по изменяемому тегу. Важно: использование доверенного CA-сертификата проблему не снимает, если hostname может также резолвиться в loopback-адрес.[3] Настоящий фикс - Engine 29.8.2. Уязвимость отчитался AdamKorcz.[3]

CVE-2026-92542 (Moderate): слепая VXLAN-инъекция в зашифрованные overlay-сети Swarm

Вторая уязвимость движка, CVE-2026-92542 (GHSA-6m9p-4h64-m6vh), оценена как Moderate с CVSS-баллом 6.9.[4] Если вы гоняете Docker Swarm на нескольких нодах с зашифрованными overlay-сетями - это прямо про вас.

Корень в том, что iptables-правила, которые помечают VXLAN-датаграммы для IPsec-шифрования, матчат любую подходящую датаграмму - и настоящий kernel-отправленный VXLAN, и сфальсифицированные датаграммы от пользовательских процессов. Любой пакет из host-network-неймспейса Linux Swarm-ноды, отвечающий трём критериям (UDP, порт назначения равен data-path порту Swarm и VXLAN-заголовок с VNI зашифрованной overlay-сети, к которой подключён контейнер на ноде), шифруется IPsec-параметрами этой overlay-сети. Непривилегированный пользователь на Linux Swarm-ноде может тривиально впрыснуть поддельные Ethernet-кадры в зашифрованную overlay-сеть на другой ноде.[4]

Последствия: непривилегированный локальный пользователь на соседней ноде может устроить denial of service, а искушённый атакующий - протащить пакеты мимо stateful-файрвола, от которого как раз должна была защищать шифрованная overlay.[4] Затронуты версии <= 25.0.18 и 26.0.0–29.8.1; исправлено в 29.8.2 (и в 25.0.19 для старой ветки).[4] Workaround из advisory - блокировать пользовательским процессам отправку UDP на data-path порт Swarm (iptables-правило с --socket-exists), но на multi-tenant Swarm правильный ответ - апгрейд.[4]

CVE-2026-53493 (Moderate): DoS на pull образов во встроенном containerd

CVE-2026-53493 (GHSA-pg57-6jwg-q645) - уязвимость containerd, которая становится проблемой Docker Engine, потому что Engine 29.x включает containerd в качестве рантайма. Оценена как Moderate с CVSS-баллом 6.9 (CWE-400/834).[2][5]

Pull сфабрикованного OCI image index с глубоко вложенными или широко разветвлёнными дескрипторами может вызвать очень высокое потребление CPU и памяти - до старта какого-либо контейнера. Поскольку резолюция графа дескрипторов в containerd рекурсировала без лимитов на глубину, ширину и повторные ссылки, одна отравленная ссылка на образ может надолго замкнуть узел на создании контейнеров, а на больших размерах - дестабилизировать хост.[5][6]

Для self-hosted машины риск концентрируется там, где вы тянете то, что не собирали сами и за что не можете поручиться: multi-tenant кластеры, CI-раннеры, тянущие произвольные базовые образы, и registry mirrors/кэши. Если каждый образ на вашей ноде приходит из registry, которым вы владеете и доверяете, - это рутинная гигиена; если какая-то нода тянет из открытого интернета или от арендаторов, которым вы не доверяете, - относитесь к этому серьёзнее.[6] Исправлено в containerd 1.7.36, 2.0.13, 2.2.9, 2.3.6 и 2.4.1; Docker Engine 29.8.2 включает containerd v2.3.6, так что апгрейд Engine и несёт этот фикс.[1][5][6]

Пакет BuildKit: краши, отравление кэша, обход source policy

Десять фиксов BuildKit (пакет исправлен во встроенном BuildKit v0.33.1) делятся на три группы.[1][2][7]

Краши демона (доступность): CVE-2026-93316 (запрошены CDI-устройства при отключённом CDI → паника демона), CVE-2026-93319 (вредоносный внешний frontend валит демон через гонки жизненного цикла gateway или сломанные запросы), CVE-2026-93321 (сломанная LLB file-операция с невалидными входами symlink-владельца) и CVE-2026-93322 (сломанная LLB merge-операция с рассинхронизированным числом входов) могут вызвать панику или краш build-демона. CVE-2026-93323 добавляет исчерпание памяти от слишком большого Dockerfile, .dockerignore, gateway-файла или вложенного LLB-определения.[2][7]

Отравление build-кэша (целостность / цепочка поставок): те две, что должны беспокоить деплой-хост больше всего. CVE-2026-93317 - с containerd image store клиент, использующий низкоуровневый LLB API, может отравить build-кэш содержимым blob-ов контейнера, не совпадающим с заявленным digest. CVE-2026-93318 - вредоносный образ может отравить build-кэш DiffID-ами слоёв, не совпадающими с реальным содержимым слоёв.[2][7] Если атакующий сможет отравить ваш кэш, более поздние сборки молча подхватят подменённый контент, и отправка его в прод - уже не экзотический баг, а компрометация цепочки поставок.

Source policy и файловая система: CVE-2026-93326 - сфабрикованный Git-build-source может обойти правила source policy, которые матчат по URL репозитория, через Git-bundle locator или полный remote URL, не совпадающий с source-идентификатором. CVE-2026-93320 - daemon-side чтения снапшотов и LLB mkfile-операции некорректно обрабатывали special-файлы, а CVE-2026-93315 позволяет build-шагу перенаправить очистку proxy-CA за пределы корневой ФС сборки или дать сборке пройти успешно, когда очистка не удалась.[2][7]

Что именно обновить и как проверить версию

Фикс - довести Docker Engine до 29.8.2 или новее на каждой ноде, которая тянет образы или запускает сборки: это ваш VPS, ваши CI-раннеры и хост, который крутит registry mirrors. Фиксы 29.8.x ушли дальше в линейку 29.9: по состоянию на 07.11.2026 текущий релиз Engine - 29.9.3 (03.11.2026, кумулятивный security-релиз поверх фикса eMudhra CA в 29.9.2), так что любая нода на 29.9.x уже несёт фиксы 29.8.2 - но ради более новых CVE всё равно стоит дойти до 29.9.3.[1] Если вы всё ещё на 29.8.0/29.8.1 - переход на ≥29.8.2 и есть тот, что закрывает баги ниже.

Обновление. Если вы ставили из apt-репозитория Docker на Debian/Ubuntu:

sudo apt-get update
sudo apt-get install --only-upgrade docker-ce docker-ce-cli containerd.io

Если используете статические бинарники или пакеты из другого дистрибутива - возьмите бинарники 29.8.2 и перезапустите демон.

Проверка версии движка после апгрейда:

docker version --format '{{.Server.Version}}'   # ожидаем 29.8.2 или новее (29.9.x на 10.2026)
docker info | grep -i "Server Version"

Поле Version секции Server - то самое число, которое важно: это версия самого движка, а не CLI. Также проверьте встроенные компоненты после чистого перезапуска:

docker buildx version    # версия встроенного BuildKit (v0.33.1+)
docker info              # убедитесь, что демон чисто перезапустился на новой версии

На self-hosted Swarm перезапускайте worker-ноды по одной, чтобы overlay не нервировал, и убедитесь, что сервисы в зашифрованных сетях поднялись, прежде чем переходить к следующей ноде.

Почему это ровно ваша проблема на self-hosted машине

Ничто из этого не требует, чтобы кто-то запускал вредоносный контейнер на вашем хосте. DNS-обход registry (92543) срабатывает, пока демон резолвит и аутентифицирует registry; DoS containerd (53493) - во время pull; отравление build-кэша BuildKit - когда вы собираете из сомнительного базового образа или frontend. Для лёгкого хоста на сыром VPS или self-hosted платформе это ровно та модель угроз, в которой вы живёте: вы тянете публичные образы, собираете на их основе и доверяете цепочке registry, чтобы это оставалось честным.

Апгрейд небольшой, хорошо обкатанный и закрывает пакет, в котором есть баг высокой серьёзности на утечку кредов и подмену образа. Проверьте, что ваши ноды на 29.8.2, сверьте версии встроенных containerd/BuildKit - и вы убрали со своей машины целое семейство attack-векторов на этапе pull.

Источники

  1. Docker - Engine 29 release notes (29.8.2, 2026-09-30; packaging: BuildKit v0.33.1, containerd v2.3.6, runc v1.5.2; текущий релиз линии 29.9.3, 2026-11-03). https://docs.docker.com/engine/release-notes/29/ - checked 2026-11-07
  2. GitHub - релиз moby/moby docker-v29.8.2 (полный список CVE + GHSA для движка и BuildKit). https://github.com/moby/moby/releases/tag/docker-v29.8.2 - checked 2026-10-02
  3. GitHub Advisory GHSA-7cfq-22r6-qp73 (moby/moby) - CVE-2026-92543, «insecure-registry fallback via malicious DNS responses», High (CVSS 7.6), патч 29.8.2. https://github.com/moby/moby/security/advisories/GHSA-7cfq-22r6-qp73 - checked 2026-10-02
  4. GitHub Advisory GHSA-6m9p-4h64-m6vh (moby/moby) - CVE-2026-92542, «blind VXLAN injection into encrypted overlay networks», Moderate (CVSS 6.9), патч 29.8.2 / 25.0.19. https://github.com/moby/moby/security/advisories/GHSA-6m9p-4h64-m6vh - checked 2026-10-02
  5. GitHub Advisory GHSA-pg57-6jwg-q645 (containerd) - CVE-2026-53493, «image-pull DoS via crafted OCI index graph amplification», Moderate, исправлено в 1.7.36 / 2.0.13 / 2.2.9 / 2.3.6 / 2.4.1. https://github.com/containerd/containerd/security/advisories/GHSA-pg57-6jwg-q645 - checked 2026-10-02
  6. containerd - запись NVD для CVE-2026-53493 (сконструированный OCI index graph может вызвать высокую загрузку CPU/памяти при pull; исправлено в 1.7.36/2.0.13/2.2.9/2.3.6/2.4.1). https://nvd.nist.gov/vuln/detail/CVE-2026-53493 - checked 2026-10-02
  7. GitHub - security advisories moby/buildkit (GHSA-2f5p-x9ph-g97x, GHSA-r456-g3gm-cvxf, GHSA-p3rc-w3hc-pqvv, GHSA-f2v9-hprr-32q3, GHSA-4hgw-qrhw-fhg8, GHSA-9728-qjrv-2xh2, GHSA-fjj4-h6vf-m9hj, GHSA-cv6p-7w7g-xjwq, GHSA-mgqf-486f-49vp, GHSA-66hf-6vf5-87hc). https://github.com/moby/buildkit/security/advisories - checked 2026-10-02