The post has been translated automatically. Original language: Russian
On September 4, 2026, the containerd team released four patch versions of container runtime at once.: 2.3.5, 2.2.8, 2.0.12 and 1.7.35. This is the layer that lies under Docker and under most Kubernetes clusters. The releases address two sustainability issues, and three days earlier, a separate critical warning was issued about restoring containers from checkpoints.
I/O streams in execSync that never close
The first vulnerability received the identifier CVE-2026-53495 and a moderate level of danger. It applies only to Linux and deployments with the containerd CRI plugin, i.e. Kubernetes nodes. The defect is in the implementation of the execSync call, which CRI executes a command inside a container and waits for the result. If an exec sample or lifecycle hook generates a background child process that lives longer than the command itself, the goroutines that subtract the standard output remain blocked: there was no timeout or context cancellation in the subtraction mechanism. Repeated execSync calls with such commands accumulate goroutines and memory until the daemon crashes due to its shortage.
All branches up to 1.7.35, 2.0.12, 2.2.8 and 2.3.5, respectively, are affected. A temporary measure, if you can't upgrade right now, is to make sure that trials and lifecycle hooks don't trigger long—lived background processes.
Unpacking an image that slows down the entire node
The second problem is the denial of service when unpacking layers, class CWE—400, "uncontrolled resource consumption"; she did not have a separate CVE number at the time of publication. A specially assembled image with repeating opaque deletion markers forces the unpacker to repeatedly go through the same directories, which makes the complexity of the operation super-linear. The result is a long decompression, high processor load, delayed container start, and less parallelism when pulling the remaining images on the node. There are no workarounds: the authors write that before the patch, all that remains is to pull images from trusted registries.
Restore from checkpoint and process rights
On the first of September, another warning was issued, already with a critical level. When restoring a container from a checkpoint via a createContainer call, the CRIU tool took the process credentials, the capabilities set, the no_new_privs flag, and the seccomp status directly from the checkpoint data, rather than from the container configuration on the destination side. The process could rise with root rights and a full set of privileges where the policy did not allow it, and the orchestrator did not find out about it. Versions 2.1.0 to 2.2.6 and 2.3.0 to 2.3.3 are affected, the fix is included in 2.2.7, 2.3.4 and 2.4.0 — the latter feature was simply removed.
What else was fixed in 2.3.5
In addition to security, everyday things are closed: races when streaming the container's I/O to CRI, user and group search errors when the passwd and group files in the container's root system turned out to be symbolic links, failure to unpack EROFS images, and daemon startup when loading PWMs.
What does this mean in practice?
Both new issues are not about data theft, but about node availability, and therefore they are easy to underestimate. The most likely scenario is not about an attacker at all: an exec test that inadvertently starts a background process has been working "normally" for years, and on a loaded node it starts eating up the daemon's memory. It's worth reviewing the manifests for trials and hooks that don't wait for child processes.
The order of updating is the usual: first the stand, then one node at a time with the displacement of the hearths. Patch versions within the minor branch are compatible, no state migration is required, but restarting containerd on a node is restarting PWMs, so it is better to schedule the maintenance window. Fixes were released for four lines at once, including the old 1.7, so there is no need to change the minor version for the sake of a patch.
The draft text was prepared with the participation of AI, the facts were checked against the original source — the official notes for the release of containerd 2.3.5 and the security warnings published by the project.
Четвёртого сентября 2026 года команда containerd выпустила сразу четыре патч-версии контейнерного рантайма: 2.3.5, 2.2.8, 2.0.12 и 1.7.35. Это тот слой, который лежит под Docker и под большинством кластеров Kubernetes. В релизах закрыты две проблемы устойчивости, а тремя днями раньше вышло отдельное критическое предупреждение про восстановление контейнеров из контрольных точек.
Потоки ввода-вывода в ExecSync, которые никогда не закрываются
Первая уязвимость получила идентификатор CVE-2026-53495 и умеренный уровень опасности. Она касается только Linux и развёртываний с CRI-плагином containerd, то есть узлов Kubernetes. Дефект — в реализации ExecSync — вызова, которым CRI выполняет команду внутри контейнера и ждёт результата. Если exec-проба или lifecycle-хук порождает фоновый дочерний процесс, который живёт дольше самой команды, горутины, вычитывающие стандартный вывод, остаются заблокированными: в механизме вычитывания не было ни таймаута, ни отмены по контексту. Повторяющиеся вызовы ExecSync с такими командами копят горутины и память вплоть до падения демона по её нехватке.
Затронуты все ветки до 1.7.35, 2.0.12, 2.2.8 и 2.3.5 соответственно. Временная мера, если обновиться прямо сейчас нельзя, — убедиться, что пробы и хуки жизненного цикла не запускают долгоживущих фоновых процессов.
Распаковка образа, которая тормозит весь узел
Вторая проблема — отказ в обслуживании при распаковке слоёв, класс CWE-400, «неконтролируемое потребление ресурсов»; отдельного номера CVE у неё на момент публикации не было. Специально собранный образ с повторяющимися непрозрачными маркерами удаления заставляет распаковщик многократно проходить по одним и тем же каталогам, из-за чего сложность операции становится суперлинейной. Итог — долгая распаковка, высокая нагрузка на процессор, задержка старта контейнеров и меньший параллелизм при вытягивании остальных образов на узле. Обходных путей нет: авторы пишут, что до патча остаётся только тянуть образы из доверенных реестров.
Восстановление из контрольной точки и права процесса
Первого сентября вышло ещё одно предупреждение, уже с критическим уровнем. При восстановлении контейнера из контрольной точки через вызов CreateContainer инструмент CRIU брал учётные данные процесса, набор capabilities, флаг no_new_privs и состояние seccomp прямо из данных контрольной точки, а не из конфигурации контейнера на стороне назначения. Процесс мог подняться с правами root и полным набором привилегий там, где политика этого не разрешала, причём оркестратор об этом не узнавал. Затронуты версии с 2.1.0 по 2.2.6 и с 2.3.0 по 2.3.3, исправление вошло в 2.2.7, 2.3.4 и 2.4.0 — в последней возможность просто убрали.
Что ещё поправили в 2.3.5
Кроме безопасности, закрыты бытовые вещи: гонки при стриминге ввода-вывода контейнера в CRI, ошибки поиска пользователя и группы, когда файлы passwd и group в корневой системе контейнера оказались символическими ссылками, сбой распаковки EROFS-образов, зависание старта демона при загрузке шимов.
Что это значит на практике
Обе новые проблемы — не про кражу данных, а про доступность узла, и потому их легко недооценить. Самый вероятный сценарий вообще не про злоумышленника: exec-проба, которая по недосмотру запускает фоновый процесс, годами работала «нормально», а на нагруженном узле начинает съедать память демона. Стоит просмотреть манифесты на предмет проб и хуков, не дожидающихся дочерних процессов.
Порядок обновления обычный: сначала стенд, потом по одному узлу с вытеснением подов. Патч-версии в пределах минорной ветки совместимы, миграции состояния не требуется, но перезапуск containerd на узле — это перезапуск шимов, поэтому окно обслуживания лучше запланировать. Исправления вышли сразу для четырёх линеек, включая старую 1.7, так что менять минорную версию ради патча не нужно.
Черновик текста подготовлен с участием ИИ, факты сверены с первоисточником — официальные заметки к выпуску containerd 2.3.5 и опубликованные проектом предупреждения безопасности.
Share
