Три нови критични уязвимости в runc – широко използваният контейнерен runtime компонент в Docker, Kubernetes и други платформи за контейнеризация – поставят под сериозен риск сигурността на инфраструктури по целия свят. Функционалността на runc е в основата на контейнерните операции и отговаря за създаването, инициализацията и управлението на контейнерите, което прави всяка уязвимост в тази компонента особено опасна.

Проблемите, регистрирани като CVE-2025-31133, CVE-2025-52565 и CVE-2025-52881, позволяват излизане от контейнера и придобиване на root достъп до хост системата. Макар активни експлойти да не са засечени към момента, атакуващите могат да използват зловредни контейнерни образи и Dockerfile конфигурации, за да задействат слабостите.

Природата на уязвимостите: излизане от контейнера чрез манипулиране на mount операции

И трите уязвимости експлоатират слабости в начина, по който runc обработва mount точки, symlink обекти и procfs записи по време на създаване на контейнера. Използват се race condition сценарии и неправилно приложени механизми за защита като maskedPaths и readonlyPaths.

Основните механизми на атаките включват:

• race-mount условия, позволяващи пренасочване на mount операции в критични системни директории;

• символни връзки, които runc обработва неправилно при създаването на контейнера;

• procfs write операции, които могат да бъдат пренасочени към чувствителни системни файлове.

Атакуващите трябва да имат възможност да стартират контейнери с custom mount конфигурации, което прави зловредните образи основният вектор.

CVE-2025-31133 – злоупотреба с maskedPaths и произволно писане върху системни файлове

MaskedPaths защитава чувствителни файлове, които не трябва да бъдат видими от контейнера. Според анализа на Sysdig, атакуващият може да замени /dev/null със symlink по време на инициализацията.

Това води до монтиране на произволни хост директории и предоставя възможност за писане върху критични файлове като:

• /proc/sys/kernel/core_pattern

Промяната на core_pattern позволява изпълнение на код при crash събитие – ключов механизъм за пробив от контейнера към хоста.

CVE-2025-52565 – експлоатация на /dev/console mount race

Недостатъчната валидация на mount операции за /dev/console позволява на атакуващия да пренасочи монтирането към непредвидени файлови точки.
Проблемът възниква, защото mount операцията се извършва преди да бъдат приложени защитите maskedPaths и readonlyPaths.

Така атакуващият получава писмен достъп до чувствителни procfs области, което позволява промяна на системни параметри и заобикаляне на изолацията.

CVE-2025-52881 – заобикаляне на LSM чрез race условия

Тази уязвимост позволява злоупотреба със споделени mount точки, чрез които атакуващият може да пренасочи runc операции към фалшиви procfs файлове.

В резултат може да бъде манипулиран достъпът до високорискови системни ресурси като:

• /proc/sysrq-trigger

• /proc/sys/kernel/core_pattern

Модифицирането им може да доведе до crash, изпълнение на код или пълно излизане от контейнера.

Таблица на уязвимостите

Препоръки за защита и смекчаване

1. Незабавно обновяване

Всички три уязвимости са поправени във версии:

• 1.2.8

• 1.3.3

• 1.4.0-rc.3 и по-нови

Обновяването трябва да бъде приоритет за всички кластери и CI/CD среди.

2. Въвеждане на user namespaces

Sysdig препоръчва активиране на user namespaces за всички контейнери.
Това ограничава достъпа до procfs и осигурява допълнителен слой изолация.

3. Използване на rootless контейнери

Rootless контейнеризацията значително намалява обхвата на успешната атака.

4. Обновяване на облачни платформи

AWS ECS/EKS и други облачни доставчици публикуваха актуализации на 5 ноември 2025 г.
Платформите трябва да бъдат синхронизирани с новите runc версии.

Макар активни експлойти да не са засечени, комбинацията от race условия, неправилно обработени mount операции и злоупотреба с procfs превръщат тези уязвимости в потенциално катастрофални. Критичният характер на runc като основна компонента за изпълнение на контейнери означава, че всяка слабост в него може да доведе до компрометиране на цели Kubernetes кластери или Docker инфраструктури.

Незабавното обновяване и правилната конфигурация са ключът към минимизиране на риска.