The post has been translated automatically. Original language: Russian
On September 24, 2026, the containerd team released five versions at once — 1.7.36, 2.0.13, 2.2.9, 2.3.6, and 2.4.1 — and fixed one common security issue with the identifier CVE-2026-53493. A defect in the image download processors: a specially assembled image index in OCI format causes the runtime to consume processor and memory without an upper limit. The danger level is rated as average, with a basic CVSS rating of 5.3. The problem concerns almost everyone who runs containers: containerd works under the hood for most Kubernetes installations, as well as for the usual local daemon.
What is the essence of the defect?
The OCI image index is a tree of descriptors: the root record refers to manifests for different architectures, and those for layers and configurations. Runtime traverses the tree recursively to figure out what to download. As follows from the security notice, two things were missing in the bypass: restrictions on the depth and width of the graph and the elimination of duplicates among identical descriptors. If you prepare an index with very deep nesting or with huge branching, where the same records occur multiple times, runtime unwinds the entire tree and re-processes what it has already seen. The volume of work grows like an avalanche from a relatively small description.
An important detail: everything happens at the stage of downloading the image, before launching the container. The sandbox, security profiles, and container limits do not help here — the load falls on the host at the time the image is received. The classification of weaknesses is uncontrolled resource consumption, unlimited memory allocation, and an excessive number of iterations.
Which versions are closed and what else is notable about the release?
All versions up to and including 1.7.35, as well as branches, are considered vulnerable. 2.0.0–2.0.12, 2.1.0–2.2.8, 2.3.0–2.3.5 and release 2.4.0. Fixes were released in 1.7.36, 2.0.13, 2.2.9, 2.3.6 and 2.4.1. A temporary measure until the patch is installed is explicitly described in the notification: download only trusted images from known registries.
Release 2.4.1 is the first patch of the 2.4 branch, in addition to the security fix, it includes 23 commits from seven contributors. From the notable:
- fixed a leak of tasks when the container was started unsuccessfully — because of it, the container was not deleted later.;
- fixed SELinux re-labeling failures on some file systems;
- fixed loading of content when repeating after the end of the stream;
- When unpacking an image, the ID display labels coming from the image annotations are now filtered out.;
- The parsing of arguments in the commands of the ctr utility has been corrected, including exporting images and launching the container.;
- The dependency library for working with the CBOR format has been updated from version 2.9.1 to 2.9.4.
What does this mean in practice?
The first thing is to understand which version of containerd actually works for you. This is usually not the version specified in the cluster manifest: the runtime comes from the distribution packages and is updated in a separate cycle. You need to check on the nodes, not in the configuration.
The second is to evaluate where the images come from. If the cluster pulls images only from its registry, the risk is low. The real surface appears where the name of the image comes from the outside: custom builds in CI, platforms where the client specifies an arbitrary link to the image, stands with public mirrors. These places are the first to be updated.
The third is to imagine what the incident looks like. The symptom does not look like an attack: the node stops having time to create containers, the time until the pods are ready increases, and the processor is busy with something. Without metrics on download duration and on the resources of the runtime itself, this reads as a "slow registry" or "network problems".
The fourth is to update within your branch: patches have been released for all five lines just in order not to jump through major versions for the sake of fixing. Updating the runtime on a node requires restarting the service, so the operation is scheduled across nodes, not across the cluster at once.
The draft text was prepared with the participation of AI, the facts were checked against the original source — the official security notice of the containerd project and release notes for version 2.4.1.
Команда containerd 24 сентября 2026 года выпустила сразу пять версий — 1.7.36, 2.0.13, 2.2.9, 2.3.6 и 2.4.1 — и закрыла ими одну общую проблему безопасности с идентификатором CVE-2026-53493. Дефект в обработчиках скачивания образов: специально собранный индекс образа в формате OCI заставляет рантайм расходовать процессор и память без верхней границы. Уровень опасности оценён как средний, базовая оценка по CVSS — 5.3. Проблема касается почти всех, кто запускает контейнеры: containerd работает под капотом и у большинства инсталляций Kubernetes, и у привычного локального демона.
В чём суть дефекта
Индекс образа в формате OCI — это дерево дескрипторов: корневая запись ссылается на манифесты под разные архитектуры, те — на слои и конфигурации. Рантайм обходит дерево рекурсивно, чтобы понять, что скачивать. Как следует из уведомления безопасности, в обходе не хватало двух вещей: ограничений на глубину и ширину графа и устранения дубликатов среди одинаковых дескрипторов. Если подготовить индекс с очень глубокой вложенностью или с огромным ветвлением, где одни и те же записи встречаются многократно, рантайм раскручивает всё дерево и повторно обрабатывает то, что уже видел. Объём работы растёт лавинообразно от сравнительно небольшого по размеру описания.
Важная деталь: всё происходит на этапе скачивания образа, до запуска контейнера. Песочница, профили безопасности и лимиты контейнера здесь не помогают — нагрузка ложится на хост в момент получения образа. Классификация слабых мест — неконтролируемое потребление ресурсов, выделение памяти без лимитов и избыточное число итераций.
Какие версии закрыты и чем ещё примечателен выпуск
Уязвимыми считаются все версии до 1.7.35 включительно, а также ветки 2.0.0–2.0.12, 2.1.0–2.2.8, 2.3.0–2.3.5 и выпуск 2.4.0. Исправления вышли в 1.7.36, 2.0.13, 2.2.9, 2.3.6 и 2.4.1. Временная мера, пока патч не установлен, в уведомлении описана прямо: скачивать только доверенные образы из известных реестров.
Выпуск 2.4.1 — первый патч ветки 2.4, кроме исправления безопасности в него вошло 23 коммита от семи участников. Из заметного:
- устранена утечка задач при неудачном старте контейнера — из-за неё контейнер потом не удалялся;
- исправлены сбои перемаркировки SELinux на некоторых файловых системах;
- починена загрузка содержимого при повторе после конца потока;
- при распаковке образа теперь отфильтровываются метки отображения идентификаторов, приходящие из аннотаций образа;
- поправлен разбор аргументов в командах утилиты ctr, включая экспорт образов и запуск контейнера;
- обновлена зависимость — библиотека работы с форматом CBOR с версии 2.9.1 до 2.9.4.
Что это значит на практике
Первое — понять, какая версия containerd у вас реально работает. Обычно это не та версия, что указана в манифесте кластера: рантайм приезжает из пакетов дистрибутива и обновляется отдельным циклом. Проверять надо на узлах, а не в конфигурации.
Второе — оценить, откуда приходят образы. Если кластер тянет образы только из своего реестра, риск невелик. Реальная поверхность появляется там, где имя образа приходит извне: пользовательские сборки в CI, платформы, где клиент указывает произвольную ссылку на образ, стенды с публичными зеркалами. Такие места обновляют первыми.
Третье — представлять, как выглядит инцидент. Симптом не похож на атаку: узел перестаёт успевать создавать контейнеры, растёт время до готовности подов, процессор занят непонятно чем. Без метрик по длительности скачивания и по ресурсам самого рантайма это читается как «медленный реестр» или «проблемы с сетью».
Четвёртое — обновляться внутри своей ветки: патчи выпущены для всех пяти линеек как раз для того, чтобы не прыгать через мажорные версии ради исправления. Обновление рантайма на узле требует перезапуска сервиса, так что операцию планируют по узлам, а не разом по кластеру.
Черновик текста подготовлен с участием ИИ, факты сверены с первоисточником — официальное уведомление безопасности проекта containerd и примечания к выпуску версии 2.4.1.
Share
