В экосистеме контейнеризации обнаружены три критические уязвимости в универсальном рантайме runC, на котором базируются Docker, Kubernetes и другие OCI-совместимые решения. Ошибки, получившие идентификаторы CVE-2025-31133, CVE-2025-52565 и CVE-2025-52881, могут позволить злоумышленнику обойти изоляцию контейнера и выполнить запись на хост-системе с правами root.
Что произошло: три CVE в контейнерном рантайме runC
О проблемах сообщил инженер SUSE и член совета Open Container Initiative (OCI) Алекса Сарай (Aleksa Sarai). RunC — эталонная реализация спецификации OCI, отвечающая за низкоуровневые операции запуска контейнеров: создание процессов и пространств имен, монтирование файловых систем, конфигурацию cgroups и другие функции, обеспечивающие изоляцию и контроль ресурсов.
Затронутые версии и доступные исправления
Согласно опубликованной информации, первая и третья уязвимости затрагивают все версии runC, тогда как вторая распространяется на сборки, начиная с 1.0.0-rc3. Исправления уже включены в релизы runC 1.2.8, 1.3.3 и 1.4.0-rc.3 (и новее). Администраторам рекомендуется оперативно обновиться до актуальных версий через дистрибутивы или менеджеры контейнеров.
Потенциальное влияние и сценарии атак
Исследователи предупреждают, что эксплуатация позволяет злоумышленнику записывать данные на хост с привилегиями root, что фактически приводит к container escape — нарушению базовой модели доверия между контейнером и хостом. По оценке специалистов Sysdig, для успешной атаки требуется возможность запускать контейнеры с кастомными настройками монтирования. Такой доступ достигается через вредоносные образы и специально подготовленные Dockerfile, в которых задаются опасные комбинации mount-опций.
Признаки эксплуатации и телеметрия
На момент публикации сообщений об активной эксплуатации в реальных атаках не поступало. При этом эксперты рекомендуют отслеживать подозрительную работу с символьными ссылками (symlinks), а также аномалии при монтировании и копировании файлов между контейнером и хостом — именно такие операции часто сопровождают попытки обхода изоляции.
Рекомендации по снижению риска для Docker и Kubernetes
1) Немедленное обновление. Обновите runC до версий 1.2.8/1.3.3/1.4.0-rc.3 или новее. Проверьте соответствующие обновления в Docker Engine, containerd и дистрибутивах Kubernetes, поскольку они подтягивают runC как зависимость.
2) Включение user namespaces. Разработчики runC советуют включить user namespace для всех контейнеров, не предоставляя контейнеру root-хоста. DAC-модель Unix ограничивает доступ к критически важным файлам и блокирует ключевые векторы эскалации.
3) Использование rootless-контейнеров. Если возможно, запускайте контейнеры в rootless-режиме. Это существенно снижает последствия компрометации, поскольку процессы контейнера не обладают привилегиями на уровне хоста.
4) Ограничение опасных политик. Сведите к минимуму привилегированные контейнеры, запретите или строго контролируйте hostPath-монтирования, избыточные capability (например, CAP_SYS_ADMIN), а также кастомные mount-опции. В Kubernetes используйте политики Admission (например, Pod Security Admission), профили seccomp и AppArmor, а также read-only root файловые системы там, где это возможно.
5) Наблюдаемость и контроль изменений. Включите детектирование операций с символьными ссылками и нестандартных монтирований в EDR/Runtime Security-инструментах. Отслеживайте создание и запуск образов из недоверенных источников, применяйте подписи образов и верификацию цепочки поставки (SBOM, подписи артефактов).
Контекст: почему это важно для облачных сред
RunC является ключевым компонентом большинства контейнерных платформ, поэтому его уязвимости имеют системный эффект. История отрасли подтверждает значимость подобных ошибок: достаточно вспомнить известный container escape в runC (например, CVE-2019-5736), после которого многие команды пересмотрели модели доверия и практики «минимальных привилегий». Текущие CVE повторно подчеркивают необходимость строгих политик запуска и постоянного мониторинга в средах CI/CD и Kubernetes.
Организациям стоит действовать проактивно: установить патчи runC, включить user namespaces, перейти на rootless-контейнеры там, где это возможно, и усилить политики запуска и мониторинг подозрительной активности. Чем быстрее будет закрыт технологический и процессный долг, тем ниже вероятность успешного обхода изоляции и связанных инцидентов в производственных кластерах.
