Source: Docker Blog — https://www.docker.com/blog/mitigating-cve-2026-31431-copy-fail-in-docker-engine/
CVE-2026-31431 — уязвимость Linux kernel, но для Docker вопрос уже: может ли контейнер добраться до интерфейса ядра, который использует эксплойт? По словам Docker, старые стандартные профили Docker Engine разрешали контейнерам создавать AF_ALG-сокеты, а они входят в задействованную поверхность системных вызовов.
Docker пишет, что его собственная инфраструктура не скомпрометирована. Это важно, но не означает, что каждый Docker-хост в безопасности. Риск зависит от версии Docker Engine и профиля безопасности контейнера.
Что, по версии Docker, попадает в зону риска#
В заметке о смягчении риска Docker говорит, что стандартные профили Docker Engine до v29.4.3 разрешали контейнерам создавать AF_ALG-сокеты. Это ключевая деталь.
AF_ALG — семейство Linux-сокетов для доступа к криптографическим API ядра. Docker связывает путь эксплуатации CVE именно с этой поверхностью сокетов. Практически это значит не то, что Docker поставил баг в ядре. Риск в том, что политика контейнеров могла оставить открытым путь к уязвимой функции ядра.
Docker утверждает, что пользователи не подвержены риску, если используют Docker Engine v29.4.3 или новее. Фрагмент источника также указывает на другие безопасные конфигурации, но предоставленный материал обрывается после «OR a.», поэтому здесь не стоит додумывать продолжение. Надежный вывод из доступного источника простой: v29.4.3 — чистая граница версии, которую называет Docker.
Почему это важно для тех, кто эксплуатирует контейнеры#
Такую уязвимость легко неверно прочитать в обе стороны.
Первое преувеличение: «Docker взломали». Docker прямо говорит, что CVE не компрометирует инфраструктуру Docker. Источник не дает оснований считать это взломом платформы Docker.
Второе преувеличение: «Это только проблема ядра, пользователям Docker можно не думать». Это тоже слишком мягкая оценка. Контейнеры используют общее ядро хоста. Если контейнер может обратиться к уязвимому интерфейсу ядра, граница контейнера становится частью расчета риска.
Поэтому стандартные профили важны. Seccomp, AppArmor и похожие политики рантайма — не декоративное усиление. Они определяют, к каким путям ядра может обращаться нагрузка. Уязвимость ядра проще сдержать, если контейнер вообще не может достучаться до нужного интерфейса.
Полезный урок здесь не в том, что «контейнеры сломаны». Он конкретнее: изоляция контейнеров сильнее, когда политика рантайма убирает лишнюю поверхность ядра. Разрешение, которое годами выглядело безвредным, может стать важным, когда баг в ядре попадает ровно в этот путь.
Что проверить сейчас#
Начните с версии Docker Engine на Linux-хостах. Если хост работает на Docker Engine v29.4.3 или новее, Docker говорит, что он не подвержен риску при условии, описанном в фрагменте блога.
Для старых версий Engine считайте, что хост требует проверки. Главный вопрос: могут ли контейнеры создавать AF_ALG-сокеты при действующей политике рантайма. Не исходите из того, что ваша среда совпадает со стандартными настройками Docker, если вы используете собственные seccomp-профили, усиленные базовые конфигурации или политики на уровне оркестрации.
Полезные проверки:
- Проверьте версию Docker Engine на всех Linux-хостах, а не только на ноутбуках разработчиков.
- Найдите хосты, которые все еще ниже v29.4.3.
- Разберитесь, используют ли нагрузки стандартные профили Docker или собственные профили.
- Проверьте, разрешено ли контейнерам создавать AF_ALG-сокеты на старых Engine.
- Сначала приоритизируйте хосты, доступные из интернета, multi-tenant-среды, CI и площадки с недоверенной нагрузкой.
CI-runner’ы требуют отдельного внимания. Они часто выполняют сторонний код, собирают недоверенные ветки и ради удобства запускаются с широкими привилегиями контейнеров. В такой комбинации «поверхность ядра, доступная из контейнера» быстро становится операционной проблемой с высоким приоритетом.
Чего не стоит утверждать#
Доступный источник не говорит, что эксплуатация уже идет in the wild. Он не дает полной цепочки эксплуатации, списка затронутых версий ядра или доказательства, что каждый Docker Engine до v29.4.3 можно проэксплуатировать. Он также не говорит, что инфраструктура Docker была взломана.
Более безопасное и полезное прочтение уже: Docker обнаружил, что старые стандартные профили Docker Engine разрешали доступ к поверхности Linux kernel-сокетов, которую использует CVE-2026-31431, а Docker Engine v29.4.3 меняет эту границу доступности.
Этого достаточно, чтобы обновляться и пересматривать политики. Но недостаточно, чтобы придумывать последствия инцидента.
Практический вывод#
Обновите Docker Engine там, где это возможно. Если быстро обновиться нельзя, проверьте профили безопасности контейнеров и запретите создание AF_ALG-сокетов там, где вашим нагрузкам это не нужно.
Операционный приоритет понятен: сначала закрыть доступ контейнеров к интерфейсу ядра, затем проверить путь обновления ядра хоста через обычный канал вашего Linux-дистрибутива. Docker может уменьшить доступность проблемы со стороны контейнеров. Сама CVE остается уязвимостью ядра.