Спор между изследовател по сигурността и Microsoft Azure постави отново въпроса за прозрачността при vulnerability disclosure процесите, след като компанията е отказала да признае уязвимост в Azure Backup for AKS, а впоследствие според изследователя е внедрила скрита поправка без публично предупреждение или CVE идентификатор.

Случаят засяга потенциална privilege escalation уязвимост, която според доклада е позволявала получаване на Kubernetes cluster-admin права чрез нископривилегированата роля „Backup Contributor“.

Изследователят твърди, че уязвимостта е позволявала пълен контрол над AKS клъстери

Уязвимостта е открита през март от изследователя Джъстин О’Лиъри.

Според него проблемът е позволявал на потребител без Kubernetes права да получи cluster-admin достъп до Azure Kubernetes Service (AKS) среди чрез механизма Trusted Access, използван от Azure Backup for AKS.

О’Лиъри твърди, че атаката не изисква предварителен административен достъп до Kubernetes клъстера, въпреки че Microsoft е характеризирала проблема именно по този начин.

По думите му:

„Уязвимостта позволява на потребител с нулеви Kubernetes права да получи cluster-admin достъп. Атаката не изисква предварителен cluster access – тя го предоставя.“

Microsoft отхвърля доклада

Според информацията Microsoft Security Response Center е отхвърлил доклада на 13 април с аргумента, че сценарият изисква предварителни административни права в средата на клиента.

Microsoft заявява, че:

• не счита поведението за security vulnerability
• не е издавала CVE
• не е публикувала CVSS оценка
• не е правила продуктови промени

Компанията също така е препоръчала на MITRE да не издава CVE идентификатор за случая.

CERT/CC първоначално валидира проблема

След отказа на Microsoft изследователят е ескалирал случая към CERT Coordination Center, откъдето според него независимо са валидирали проблема и са му присвоили проследяващ идентификатор:

• VU#284781

CERT/CC първоначално е планирал публично разкриване за 1 юни 2026 г., но впоследствие случаят е бил затворен по CNA hierarchy rules, което оставя Microsoft с окончателната власт върху CVE процеса за собствените ѝ продукти.

Как е работела атаката

Azure Backup for AKS използва Trusted Access механизъм, чрез който backup extensions получават cluster-admin права вътре в Kubernetes клъстера.

Според О’Лиъри атакуващ с единствено:

• Backup Contributor

роля върху backup vault е можел да активира backup функционалността върху таргетиран AKS клъстер.

В резултат Azure автоматично е конфигурирал Trusted Access връзка с cluster-admin привилегии.

Това е позволявало:

• извличане на secrets
• достъп до backup данни
• възстановяване на злонамерени workloads
• пълен контрол върху клъстера

Изследователят класифицира проблема като:

• CWE-441 Confused Deputy

Тоест ситуация, при която взаимодействието между Azure RBAC и Kubernetes RBAC води до неочаквано заобикаляне на оторизационните граници.

Поведението на системата се е променило след доклада

Въпреки твърденията на Microsoft, че „не са правени продуктови промени“, О’Лиъри твърди, че първоначалният exploit вече не работи.

Според него Azure вече връща нови грешки като:

• UserErrorTrustedAccessGatewayReturnedForbidden
• The Trusted Access role binding is missing/has gotten removed

Освен това:

• Trusted Access вече трябва да се конфигурира ръчно
• добавени са нови permission проверки
• vault MSI вече изисква Reader права
• AKS cluster MSI вече изисква Contributor permissions върху snapshot resource groups

Всичко това според изследователя подсказва, че Microsoft реално е коригирала проблема без официално признание.

Липсата на CVE създава проблем за защитата

Един от основните проблеми според експертите е липсата на прозрачност за клиентите.

Без:

• CVE идентификатор
• advisory
• remediation timeline
• exposure window

много организации не могат ефективно да проследят дали са били изложени на риск.

О’Лиъри предупреждава, че организации, предоставили Backup Contributor роли до май 2026 г., може да са били изложени на privilege escalation риск без да знаят.

Спорът показва по-дълбок проблем във vulnerability disclosure процеса

Случаят отразява растящото напрежение между:

• security researcher-ите
• големи технологични компании
• CVE/CNA екосистемата

През последните години подобни конфликти стават все по-чести, особено при cloud услуги, където границите между „feature“ и „vulnerability“ често са спорни.

Допълнително напрежение създават:

• огромният обем vulnerability reports
• AI-assisted submissions
• претоварените bug bounty програми
• конфликтът на интереси при self-assigned CNA модели

Защо cloud средите правят проблема още по-сериозен

При cloud инфраструктурите „тихите“ поправки са особено проблематични, защото клиентите:

• нямат достъп до backend инфраструктурата
• не виждат patch timeline
• не могат да валидират exposure периода
• често разчитат изцяло на vendor transparency

Това прави публичните advisories и CVE идентификаторите ключови за enterprise risk management и incident response процесите.