Containerd
Уязвимости
22
Эксплуатируемые
0
Макс. CVSS
8.8
Макс. EPSS
0.27392
Распределение по критичности
Критический
0
Высокий
7
Средний
10
Низкий
0
Также сопоставлено как (исходные строки): containerd
Топ уязвимостей
CVE-2020-15257containerd — это стандартная среда выполнения контейнеров и доступна в виде демона для Linux и Windows. В containerd до версий 1.3.9 и 1.4.3 API containerd-shim неправильно предоставляется контейнерам хост-сети. Элементы управления доступом для сокета API shim проверяли, что подключающийся процесс имеет эффективный UID 0, но в противном случае не ограничивали доступ к абстрактному сокету домена Unix. Это позволило бы вредоносным контейнерам, работающим в том же сетевом пространстве имен, что и shim, с эффективным UID 0, но в остальном с уменьшенными привилегиями, запускать новые процессы с повышенными привилегиями. Эта уязвимость была исправлена в containerd 1.3.9 и 1.4.3. Пользователи должны обновиться до этих версий, как только они будут выпущены. Следует отметить, что контейнеры, запущенные со старой версией containerd-shim, следует остановить и перезапустить, так как работающие контейнеры останутся уязвимыми даже после обновления. Если вы не предоставляете возможность ненадежным пользователям запускать контейнеры в том же сетевом пространстве имен, что и shim (обычно сетевое пространство имен «хост», например, с docker run --net=host или hostNetwork: true в поде Kubernetes) и запускать с эффективным UID 0, вы не уязвимы для этой проблемы. Если вы запускаете контейнеры с уязвимой конфигурацией, вы можете запретить доступ ко всем абстрактным сокетам с помощью AppArmor, добавив строку, подобную deny unix addr=@**, в свою политику. Лучше всего запускать контейнеры с уменьшенным набором привилегий, с ненулевым UID и с изолированными пространствами имен. Разработчики containerd настоятельно не рекомендуют совместно использовать пространства имен с хостом. Уменьшение набора механизмов изоляции, используемых для контейнера, обязательно увеличивает привилегии этого контейнера, независимо от того, какая среда выполнения контейнера используется для запуска этого контейнера.
CVE-2021-43816containerd — это среда выполнения контейнеров с открытым исходным кодом. В установках, использующих SELinux, таких как EL8 (CentOS, RHEL), Fedora или SUSE MicroOS, с containerd, начиная с v1.5.0-beta.0, в качестве интерфейса среды выполнения контейнеров (CRI), непривилегированный модуль pod, запланированный для узла, может подключить, через том hostPath, любой привилегированный обычный файл на диске для полного доступа для чтения/записи (без удаления). Это достигается путем размещения местоположения в контейнере точки монтирования тома hostPath либо в `/etc/hosts`, `/etc/hostname` или `/etc/resolv.conf`. Эти местоположения перемаркируются без разбора в соответствии с меткой процесса контейнера, что эффективно повышает разрешения для подкованных контейнеров, которые обычно не могут получить доступ к привилегированным файлам хоста. Эта проблема была решена в версии 1.5.9. Пользователям рекомендуется как можно скорее выполнить обновление.
CVE-2024-40635containerd является открытым контейнерным временем выполнения. В containerd до версий 1.6.38, 1.7.27 и 2.0.4 была обнаружена ошибка, из-за которой контейнеры, запущенные с пользователем, установленным как `UID:GID`, большими, чем максимальное 32-битное знаковое целое, могут вызвать переполнение, в результате чего контейнер в конечном итоге запускается как root (UID 0). Это может вызвать неожиданные последствия для окружений, требующих запуска контейнеров от имени пользователя, не являющегося root. Эта ошибка была исправлена в containerd 1.6.38, 1.7.27 и 2.04. В качестве временного решения убедитесь, что используются только надежные образы, и что только доверенные пользователи имеют разрешения на импорт изображений.
CVE-2024-25621Контейнерный контейнер - это время работы контейнеров с открытым исходным кодом. Версий 0.1.0 - 1.7.28, 2.0.0-beta.0 до 2.0.6, 2.1.0-beta.0 до 2.1.4 и 2.2.0-beta.0 до 2.2.0-rc.1 имеют слишком широкую уязвимость разрешения по умолчанию. Пути справочника `/var/lib/containerd`, `/run/containerd/containerd.sandbox.grp.v1.cri` и `/run/containerd/io.containerd.sandbox.control.v1.sm` и `/run/containerd/io.containerd.sandbox.control.v1.sym` и `/run/containerd.sandbox.control.v1. Эта проблема исправлена в версиях 1.7.29, 2.0.7, 2.1.5 и 2.2.0. Процедуры включают обновление разрешений системного администратора, чтобы хост мог вручную перерабатывать каталоги, чтобы не иметь групповых или мировых доступных разрешений или запускать контейнеры в режиме без корней.
CVE-2025-47290В containerd версии 2.1.0 обнаружена уязвимость типа TOCTOU, позволяющая специальным образом созданным образам контейнеров произвольно изменять файловую систему хоста. Проблема исправлена в версии 2.1.1. В качестве обходного пути рекомендуется использовать только доверенные образы и ограничить доступ к импорту образов [1].
Источники:
- [1] https://github.com/containerd/containerd/security/advisories/GHSA-cm76-qm8v-3j95
- [2] https://github.com/containerd/containerd/commit/cada13298fba85493badb6fecb6ccf80e49673cc
- [3] https://github.com/containerd/containerd/releases/tag/v2.1.1
CVE-2022-23648containerd — это среда выполнения контейнеров, доступная в виде демона для Linux и Windows. В containerd до версий 1.6.1, 1.5.10 и 1.14.12 была обнаружена ошибка, из-за которой контейнеры, запущенные через реализацию CRI containerd в Linux со специально созданной конфигурацией образа, могли получить доступ для чтения к копиям произвольных файлов и каталогов, доступных только для чтения, на хосте. Это может обойти любое принудительное применение на основе политик при настройке контейнера (включая политику безопасности Pod Kubernetes) и раскрыть потенциально конфиденциальную информацию. Kubernetes и crictl можно настроить для использования реализации CRI containerd. Эта ошибка была исправлена в containerd 1.6.1, 1.5.10 и 1.4.12. Пользователям следует обновиться до этих версий, чтобы устранить проблему.
CVE-2023-25173containerd - это программное обеспечение с открытым исходным кодом для работы с контейнерами. В containerd до версий 1.6.18 и 1.5.18 была обнаружена ошибка, из-за которой дополнительные группы не настраивались должным образом внутри контейнера. Если злоумышленник имеет прямой доступ к контейнеру и манипулирует своим доступом к дополнительным группам, он может использовать доступ к дополнительным группам для обхода ограничений основной группы в некоторых случаях, потенциально получая доступ к конфиденциальной информации или возможность выполнять код в этом контейнере. Приложения, использующие библиотеку клиентских контейнеров containerd, также могут быть затронуты.
Эта ошибка была исправлена в containerd v1.6.18 и v.1.5.18. Пользователи должны обновить свои версии до этих, а также воссоздать контейнеры для решения данной проблемы. Пользователям, полагающимся на сторонние приложения, использующие библиотеку клиентских контейнеров containerd, следует проверить это приложение на наличие отдельного уведомления и инструкций. В качестве временного решения необходимо убедиться, что инструкция Dockerfile `"USER $USERNAME"` не используется. Вместо этого установите точку входа контейнера на значение, подобное `ENTRYPOINT ["su", "-", "user"]`, чтобы позволить `su` правильно настроить дополнительные группы.
CVE-2025-64329Контейнерный контейнер - это контейнерное время работы с открытым исходным кодом. Версии 1.7.28 и ниже, 2.0.0-beta.0 до 2.0.6, 2.1.0-beta.0 до 2.1.4 и 2.2.0-beta.0 до 2.2.0-rc.1 содержат ошибку в реализации CRI Attach, где пользователь может исчерпать память на хостере из-за утечек горотины. Эта проблема исправлена в версиях 1.7.29, 2.0.7, 2.1.5 и 2.2.0. Чтобы обойти эту уязвимость, пользователи могут настроить контроллер допуска для управления доступами к ресурсам pods/attach.
CVE-2022-23471containerd — это открытая среда выполнения контейнеров. В реализации CRI containerd была обнаружена ошибка, при которой пользователь может истощить память на хосте. В сервере потока CRI запускается горутина для обработки событий изменения размера терминала, если запрашивается TTY. Если процесс пользователя не удается запустить из-за, например, неправильно указанной команды, горутина будет застревать в ожидании отправки без получателя, что приведет к утечке памяти. Kubernetes и crictl могут быть настроены на использование реализации CRI containerd, и сервер потока используется для обработки ввода-вывода контейнера. Эта ошибка была исправлена в containerd 1.6.12 и 1.5.16. Пользователи должны обновиться до этих версий, чтобы решить проблему. Пользователям, которые не могут обновиться, следует убедиться, что используются только доверенные образы и команды, а также что только доверенные пользователи имеют разрешения на выполнение команд в работающих контейнерах.
CVE-2021-21334В containerd (стандартная отраслевая среда выполнения контейнеров) до версий 1.3.10 и 1.4.4 контейнеры, запущенные через реализацию CRI containerd (через Kubernetes, crictl или любой другой клиент pod/контейнера, использующий службу containerd CRI), которые совместно используют один и тот же образ, могут получать неверные переменные среды, включая значения, определенные для других контейнеров. Если затронутые контейнеры имеют разные контексты безопасности, это может привести к непреднамеренному обмену конфиденциальной информацией. Если вы не используете реализацию CRI containerd (через один из механизмов, описанных выше), вы не уязвимы для этой проблемы. Если вы не запускаете несколько контейнеров или Kubernetes pods из одного и того же образа, у которых есть разные переменные среды, вы не уязвимы для этой проблемы. Если вы не запускаете несколько контейнеров или Kubernetes pods из одного и того же образа в быстрой последовательности, у вас снижается вероятность быть уязвимым для этой проблемы. Эта уязвимость была исправлена в containerd 1.3.10 и containerd 1.4.4. Пользователи должны обновиться до этих версий.
CVE-2020-15157В containerd (стандартная среда выполнения контейнеров) до версии 1.2.14 существует уязвимость утечки учетных данных. Если манифест образа контейнера в формате OCI Image или Docker Image V2 Schema 2 включает URL-адрес местоположения определенного слоя образа (также известного как "иностранный слой"), средство разрешения containerd по умолчанию будет следовать этому URL-адресу, чтобы попытаться загрузить его. В v1.2.x, но не в 1.3.0 или более поздней версии, средство разрешения containerd по умолчанию предоставит свои учетные данные аутентификации, если сервер, где находится URL-адрес, представит код состояния HTTP 401 вместе со специфичными для реестра заголовками HTTP. Если злоумышленник публикует общедоступный образ с манифестом, который направляет один из слоев для получения с веб-сервера, который они контролируют, и он обманом заставляет пользователя или систему извлекать образ, он может получить учетные данные, используемые для извлечения этого образа. В некоторых случаях это может быть имя пользователя и пароль пользователя для реестра. В других случаях это могут быть учетные данные, привязанные к виртуальному экземпляру облака, которые могут предоставить доступ к другим облачным ресурсам в учетной записи. Средство разрешения containerd по умолчанию используется плагином cri-containerd (который может использоваться Kubernetes), инструментом разработки ctr и другими клиентскими программами, которые явно связаны с ним. Эта уязвимость была исправлена в containerd 1.2.14. containerd 1.3 и более поздние версии не подвержены этой проблеме. Если вы используете containerd 1.3 или более позднюю версию, вы не подвержены этой проблеме. Если вы используете cri-containerd в серии 1.2 или более ранней, вы должны убедиться, что извлекаете образы только из доверенных источников. Другие среды выполнения контейнеров, построенные на основе containerd, но не использующие средство разрешения по умолчанию (например, Docker), не подвержены этой проблеме.
CVE-2021-41103containerd - это среда выполнения контейнеров с открытым исходным кодом, в которой особое внимание уделяется простоте, надежности и переносимости. В containerd была обнаружена ошибка, из-за которой корневые каталоги контейнеров и некоторые плагины имели недостаточно ограниченные разрешения, что позволяло непривилегированным пользователям Linux перемещаться по содержимому каталогов и выполнять программы. Когда контейнеры содержали исполняемые программы с расширенными битами разрешений (например, setuid), непривилегированные пользователи Linux могли обнаруживать и выполнять эти программы. Когда UID непривилегированного пользователя Linux на хосте совпадал с владельцем файла или группой внутри контейнера, непривилегированный пользователь Linux на хосте мог обнаруживать, читать и изменять эти файлы. Эта уязвимость была устранена в containerd 1.4.11 и containerd 1.5.7. Пользователям следует обновиться до этих версий, когда они будут выпущены, и перезапустить контейнеры или обновить разрешения каталогов, чтобы устранить уязвимость. Пользователям, не имеющим возможности обновиться, следует ограничить доступ к хосту доверенными пользователями. Обновите разрешения каталогов в каталогах пакетов контейнеров.
CVE-2023-25153containerd — это среда выполнения контейнеров с открытым исходным кодом. До версий 1.6.18 и 1.5.18 при импорте образа OCI не было ограничения на количество байтов, считываемых для определенных файлов. Злонамеренно созданный образ с большим файлом, для которого не было применено ограничение, мог вызвать отказ в обслуживании. Эта ошибка была исправлена в containerd 1.6.18 и 1.5.18. Пользователям следует обновиться до этих версий, чтобы устранить проблему. В качестве обходного пути убедитесь, что используются только доверенные образы и что только доверенные пользователи имеют разрешения на импорт образов.
CVE-2022-31030containerd — это среда выполнения контейнеров с открытым исходным кодом. В реализации CRI containerd была обнаружена ошибка, из-за которой программы внутри контейнера могут приводить к неограниченному потреблению памяти демоном containerd во время вызова API `ExecSync`. Это может привести к тому, что containerd потребит всю доступную память на компьютере, отказывая в обслуживании другим законным рабочим нагрузкам. Kubernetes и crictl можно настроить для использования реализации CRI containerd; `ExecSync` можно использовать при выполнении проверок или при выполнении процессов через средство "exec". Эта ошибка была исправлена в containerd 1.6.6 и 1.5.13. Пользователям следует обновиться до этих версий, чтобы устранить проблему. Пользователям, которые не могут выполнить обновление, следует убедиться, что используются только доверенные образы и команды.
CVE-2021-32760containerd — это среда выполнения контейнеров. В containerd версий до 1.4.8 и 1.5.4 была обнаружена ошибка, из-за которой извлечение специально созданного образа контейнера может привести к изменению разрешений файлов Unix для существующих файлов в файловой системе хоста. Изменения разрешений файлов могут запретить доступ ожидаемому владельцу файла, расширить доступ к другим или установить расширенные биты, такие как setuid, setgid и sticky. Эта ошибка напрямую не позволяет читать, изменять или выполнять файлы без дополнительного взаимодействующего процесса. Эта ошибка была исправлена в containerd 1.5.4 и 1.4.8. В качестве обходного пути убедитесь, что пользователи извлекают образы только из доверенных источников. Модули безопасности Linux (LSM), такие как SELinux и AppArmor, могут ограничить файлы, потенциально затронутые этой ошибкой, с помощью политик и профилей, которые запрещают containerd взаимодействовать с определенными файлами.
CVE-2022-24769Moby — это проект с открытым исходным кодом, созданный Docker для обеспечения и ускорения контейнеризации программного обеспечения. В Moby (Docker Engine) до версии 20.10.14 была обнаружена ошибка, из-за которой контейнеры некорректно запускались с непустыми наследуемыми возможностями процесса Linux, создавая нетипичную среду Linux и позволяя программам с наследуемыми возможностями файлов повышать эти возможности до разрешенного набора во время `execve(2)`. Обычно, когда исполняемые программы указали разрешенные возможности файлов, в противном случае непривилегированные пользователи и процессы могут выполнять эти программы и получать указанные возможности файлов вплоть до ограничивающего набора. Из-за этой ошибки контейнеры, которые включали исполняемые программы с наследуемыми возможностями файлов, позволяли непривилегированным пользователям и процессам дополнительно получать эти наследуемые возможности файлов вплоть до ограничивающего набора контейнера. Контейнеры, которые используют пользователей и группы Linux для выполнения разделения привилегий внутри контейнера, подвержены наиболее прямому воздействию. Эта ошибка не повлияла на песочницу безопасности контейнера, поскольку наследуемый набор никогда не содержал больше возможностей, чем было включено в ограничивающий набор контейнера. Эта ошибка была исправлена в Moby (Docker Engine) 20.10.14. Запущенные контейнеры следует остановить, удалить и воссоздать, чтобы сбросить наследуемые возможности. Это исправление изменяет поведение Moby (Docker Engine) таким образом, что контейнеры запускаются с более типичной средой Linux. В качестве обходного решения точку входа контейнера можно изменить, чтобы использовать утилиту, такую как `capsh(1)`, для удаления наследуемых возможностей до запуска основного процесса.
CVE-2025-47291В containerd, среде выполнения контейнеров с открытым исходным кодом, обнаружена ошибка в реализации CRI, где containerd, начиная с версии 2.0.1 и до версии 2.0.5, не помещает контейнера с пользовательским пространством имен в иерархию cgroup Kubernetes, поэтому некоторые ограничения Kubernetes не соблюдаются. Это может привести к отказу в обслуживании узла Kubernetes. Эта ошибка исправлена в containerd версии 2.0.5+ и 2.1.0+. Пользователям следует обновиться до этих версий, чтобы решить проблему. В качестве обходного пути можно временно отключить контейнера с пользовательским пространством имен в Kubernetes [1].
Источники:
- [1] https://github.com/containerd/containerd/security/advisories/GHSA-cxfp-7pvr-95ff
CVE-2026-53492CVE-2026-53492
CVE-2026-53489CVE-2026-53489
CVE-2026-53488CVE-2026-53488
CVE-2026-50195CVE-2026-50195
CVE-2026-47262CVE-2026-47262