У провідному OCI-рантаймі runC, на якому працюють Docker, Kubernetes та інші сумісні платформи, виявлено три критичні уразливості: CVE-2025-31133, CVE-2025-52565 і CVE-2025-52881. Їх експлуатація може дозволити зловмиснику записувати дані на хості з правами root, тобто здійснити container escape і зруйнувати модель ізоляції між контейнером і хост-системою.
Що сталося: три CVE в OCI-рантаймі runC
Про проблеми повідомив інженер SUSE і член ради Open Container Initiative Aleksa Sarai. runC — еталонна реалізація специфікації OCI, що відповідає за низькорівневий запуск контейнерів: створення процесів і просторів імен, монтування файлових систем, конфігурацію cgroups та інші механізми контролю ресурсів і ізоляції.
Які версії вразливі та де вже є виправлення
За опублікованими даними, перша і третя уразливості стосуються усіх версій runC, тоді як друга впливає на збірки, починаючи з 1.0.0-rc3. Патчі включено до релізів runC 1.2.8, 1.3.3 і 1.4.0-rc.3 (та новіших). Рекомендовано терміново оновитися через дистрибутиви, Docker Engine або containerd, які постачають runC як залежність.
Вектор атак і вплив на Docker/Kubernetes
За оцінкою фахівців Sysdig, для успішної експлуатації нападнику зазвичай потрібна можливість запускати контейнери з кастомними параметрами монтування. Такий доступ часто реалізується через шкідливі образи і спеціально підготовлені Dockerfile із небезпечними комбінаціями mount-опцій. Наслідок — потенційний запис на хості з правами root, що напряму загрожує кластерам Kubernetes і вузлам з Docker.
Ознаки експлуатації та що моніторити
Станом на момент публікації повідомлень про активну експлуатацію немає. Водночас команди безпеки мають відстежувати аномалії монтування, підозрілі операції з символьними посиланнями (symlink) та незвичні копіювання між контейнером і хостом — саме такі події часто супроводжують спроби обходу ізоляції.
Як знизити ризики: практичні кроки для DevOps і SecOps
1) Негайне оновлення. Перейдіть на runC 1.2.8/1.3.3/1.4.0-rc.3 або новіші версії. Переконайтеся, що оновлені також Docker Engine, containerd і дистрибутиви Kubernetes, які тягнуть runC транзитивно.
2) Ввімкніть user namespaces. Запускайте контейнери з user namespace, не делегуючи контейнеру root-хоста. Така модель DAC в Unix істотно обмежує доступ до критичних файлів і зменшує площу ескалації.
3) Використовуйте rootless-контейнери. За можливості обирайте rootless-режим. Навіть у випадку компрометації процеси контейнера не матимуть привілеїв на рівні хоста.
4) Обмежте небезпечні політики. Мінімізуйте privileged-контейнери, забороняйте або жорстко контролюйте hostPath-монтування, надлишкові capabilities (зокрема CAP_SYS_ADMIN) і кастомні mount-опції. У Kubernetes застосовуйте Pod Security Admission, профілі seccomp і AppArmor, а також read-only root ФС там, де це можливо.
5) Підвищте спостережуваність. Включіть детектування symlink-операцій і нетипових монтувань у EDR/Runtime Security. Використовуйте підписування образів, верифікуйте ланцюжок постачання (SBOM, підписи артефактів) і обмежуйте запуск образів із недовірених джерел.
Чому це критично для хмар і CI/CD
runC — системоутворювальний компонент більшості контейнерних платформ, тож його уразливості мають ланцюговий ефект. Галузь уже переживала подібні інциденти — достатньо згадати CVE-2019-5736, після якого багато команд переглянули принцип мінімальних привілеїв і підходи до ізоляції. Поточні CVE знову підкреслюють потребу в суворих політиках запуску та безперервному моніторингу у Kubernetes і CI/CD-конвеєрах.
Зволікати з оновленням неприпустимо: встановіть патчі runC, ввімкніть user namespaces, перейдіть на rootless там, де дозволяє архітектура, посильте політики доступу й видимість подій виконання. Чим швидше буде закрито технологічний борг, тим менший ризик успішного container escape і пов’язаних інцидентів у виробничих кластерах.
