Red Hat разкри критична уязвимост за ескалация на привилегии, проследявана като CVE-2026-10090, която засяга контролера Application Subscription в Red Hat Advanced Cluster Management за Kubernetes (ACM).

Оценена като важна с CVSS рейтинг 9.9, уязвимостта позволява на потребител с права за редактиране („edit“) само в рамките на определено именно пространство (namespace) в ACM центъра да ескалира своите привилегии до пълни администраторски права за целия клъстер (cluster-admin). Това на практика дава контрол на вътрешни лица с ниски привилегии върху цялата управлявана клъстерна инфраструктура.

Проблемът се намира в компонента multicluster-operators-subscription, който управлява функцията Application Subscription в ACM. Според съобщението за сигурност на Red Hat, потребител с базови права за редактиране в именното пространство на центъра може да създаде ресурс от тип Channel, сочещ към Helm хранилище, което той контролира, и след това да го свърже с ресурс от тип Subscription, рефериращ към този канал.

Контролерът app-subscription обработва тази заявка, използвайки своите собствени разширени системни привилегии, вместо реалните права на потребителя, който е изпратил заявката. От ключово значение е, че той никога не проверява дали лицето, създаващо абонамента, действително притежава ролята „open-cluster-management:subscription-admin“, и не ограничава ресурсите, които се внедряват, до собственото именно пространство на абонамента.

Поради тази липсваща проверка за оторизация, атакуващият може да вгради обекти с обхват на ниво клъстер в своя злонамерен Helm чарт – най-вече ClusterRoleBinding, който свързва неговия ServiceAccount с вградената роля „cluster-admin“. След като контролерът приложи чарта, това свързване се създава с пълни привилегии и атакуващият моментално става администратор на клъстера.

Red Hat класифицира основната слабост като CWE-267 (Дефиниране на привилегия с небезопасни действия), а недостатъкът е документиран в Bugzilla под номер 2483292.

Тази уязвимост е особено сериозна, тъй като директно противоречи на документирания модел за сигурност на ACM, според който потребители без права на администратор на абонаменти трябва да могат да внедряват ресурси единствено в собственото си именно пространство за абонаменти.

Организациите, разчитащи на ACM за налагане на изолация между отделните клиенти (multi-tenant) в управляваните от центъра клъстери, могат неволно да изложат всеки управляван клъстер на риск от превземане от страна на всеки потребител, който има просто ниво на достъп за редактиране до едно-единствено именно пространство – ниво на привилегии, което често се предоставя широко на разработчици и приложни екипи.

Тъй като ACM се внедрява широко в корпоративни и правителствени среди за централизирано управление на множество OpenShift и Kubernetes клъстери, успешното експлоатиране може да ескалира далеч отвъд едно именно пространство, давайки на атакуващите възможност да четат тайни ключове, да променят работни товари или да се прехвърлят във всеки клъстер, регистриран към този център.

В съобщението на Red Hat се отбелязва, че в момента няма конкретно временно решение, което да отговаря на критериите на компанията за лесно внедряване, приложимост в различните инсталации или дългосрочна стабилност.

Засегнатият пакет е идентифициран като rhacm2/multicluster-operators-subscription-rhel9 в Red Hat Advanced Cluster Management за Kubernetes 2, а текущото му състояние е посочено като „Засегнат“, без все още да е издадена корекция (errata).

До пускането на официална корекция за сигурност екипите по сигурността трябва да одитират кой притежава достъп за редактиране на ниво именно пространство в ACM центровете, да наблюдават внимателно създаването на ресурси Channel и Subscription за неоторизирани препратки към Helm хранилища и стриктно да ограничат привилегиите „subscription-admin“ само до доверени администратори.

Активирането на политики за контрол на достъпа (admission control policies), които блокират внедряването на ресурси с клъстерен обхват чрез абонаменти за приложения, също е препоръчително като временна компенсираща мярка, докато Red Hat финализира официалното отстраняване на уязвимостта.