Импорт контрольной точки CRI в Containerd допускает удалённое выполнение произвольного кода

Containerd - среда выполнения контейнеров. Её применяют в кластерах Kubernetes, в облачных сервисах и в корпоративной инфраструктуре. Уязвимость кроется в процедуре импорта контрольной точки CRI, то есть в механизме восстановления состояния контейнера из сохранённого снимка. Проверка подлинности данных там недостаточна. Поэтому среда принимает снимок из недостоверного источника и обрабатывает его как доверенный. В результате удалённый злоумышленник получает возможность выполнить произвольный код. Уязвимость получила идентификатор CVE-2026-50195 и запись BDU:2026-15942 в Банке данных угроз безопасности информации.

Детали уязвимости

Ошибка относится к классу многофакторных. Её описывают через два типа: недостаточная проверка подлинности данных и включение функций из недостоверной контролируемой области. Проще говоря, компонент импорта доверяет содержимому файла контрольной точки. Из-за этого становятся возможны подмена данных при взаимодействии и манипулирование ресурсами. Оценка по CVSS версии 3.1 составляет 9,9. Версия 2.0 даёт 9. Для эксплуатации нужен удалённый доступ и низкие привилегии. Взаимодействие пользователя при этом не требуется. Последствия затрагивают всю систему, ведь область безопасности меняется.

Механика атаки выглядит так. Злоумышленник готовит контрольную точку и передаёт её туда, где среда ожидает получить снимок. Компонент импорта не сверяет источник данных должным образом. Следовательно, содержимое снимка исполняется с правами самой среды выполнения. Этот уровень обычно выше, чем права обычного контейнера. К тому же код получает доступ к внутренним структурам среды. Оттуда открывается путь к данным приложений и к самому узлу.

Контейнеры давно перестали быть экспериментом. На них работают банковские сервисы, промышленные платформы и государственные системы. Значит, ошибка в среде выполнения затрагивает широкий круг организаций. Уязвимы версии Containerd от 2.1.0 до 2.1.9, от 2.2.0 до 2.2.5 и от 2.3.0 до 2.3.2. В список также попали Ubuntu 22.04 LTS, 24.04 LTS, 25.10 и 26.04 LTS, операционная система РЕД ОС версий 7.3 и 8.0, а также Red Hat Hardened Images.

Многие администраторы получают Containerd не напрямую, а вместе с дистрибутивом. Поэтому важно обновлять не только сам проект, но и пакеты операционной системы. Для РЕД ОС исправления размещены в репозиториях обновлений. Для Ubuntu выпуски доступны в штатных каналах распространения. У Red Hat сведения собраны в бюллетене безопасности. Идентификатор CVE-2026-50195 помогает быстро найти нужный выпуск.

Отдельного внимания заслуживает сценарий с общей инфраструктурой. Если один кластер обслуживает несколько команд или заказчиков, то исполнение чужого кода внутри среды выполнения ломает границы между ними. Злоумышленник с низкими правами может добраться до чужих данных, изменить их или нарушить работу сервисов. Высокая оценка уязвимости объясняется именно этим: изменяется область безопасности, а ущерб выходит за пределы одного компонента.

Сведения о наличии готового эксплойта пока уточняются. Данных о реальных атаках с применением этой ошибки нет. Тем не менее производители подтвердили проблему, а значит, проверять свою инфраструктуру стоит без промедления. Особенно это касается организаций, которые переносят контрольные точки между узлами или между средами.

Производители подготовили исправления. В самом Containerd проблему закрыли за пределами перечисленных диапазонов версий. Администраторам стоит сверить установленные версии с исправленными и обновить среду выполнения. Публичные бюллетени с техническими подробностями размещены в репозитории проекта Containerd, а также в базах Canonical и Red Hat. Обновление разрывает саму цепочку эксплуатации, поскольку убирает доверие к недостоверному снимку.

Контрольные точки CRI нужны для переноса и восстановления рабочих нагрузок между узлами. Следовательно, каналы импорта таких снимков требуют не меньшего контроля, чем сетевые интерфейсы. Ограничение прав на импорт и проверка источников снижают риск. Служебные данные внутри инфраструктуры заслуживают такой же проверки, как и внешние. Пока одни организации спешат с обновлением, другие тянут с установкой исправлений. Такой разрыв делает контейнерные платформы удобной целью для тех, кто ищет слабое звено.

Детали уязвимости

Ссылки