HashiCorp публикува корекции за заобикаляне на оторизацията в Consul-k8s, което би могло да позволи на атакуващ да получи повишени привилегии в Consul от друго именно пространство (namespace) в Kubernetes.

Проследявана под номер CVE-2026-110720, уязвимостта засяга внедрявания, използващи автоматизирано управление на списъците за контрол на достъпа (ACL) на системата. HashiCorp разкри проблема на 26 октомври 2026 г. и посочи версиите Consul-k8s 2.1.0 и 1.8.18 като коригирани издания.

Официалният бюлетин за сигурност определя засегнатия диапазон от версии от 0.42.0 до 2.0.4, като 1.8.18 е налична като обновена версия с отстранена уязвимост.

Въпреки че заглавието на статията описва уязвимостта като критична, бюлетинът не предоставя оценка за тежест или CVSS резултат. Пропускът се намира в правилата за свързване на ACL на компонентите, които свързват идентификаторите в Kubernetes с разрешенията в Consul.

Когато управлението на системните ACL е активирано, Consul-k8s конфигурира автентикация в Kubernetes и правила за свързване, така че неговите компоненти да могат да получават токени за Consul.

Тези правила би трябвало да свързват ServiceAccount на всеки компонент в Kubernetes със съответната му роля в Consul. Засегнатите правила обаче не ограничават последователно автентикацията само до ServiceAccounts в рамките на именното пространство в Kubernetes, в което се намира внедряването на Consul.

Това липсващо ограничение би могло да позволи на идентификационен профил от друго именно пространство да се автентикира като компонент на Consul и да получи привилегиите на този компонент. Резултатът е пробив през предвидена граница за достъп, а не просто грешка при проверка за наличие на токен.

Експлоатацията изисква специфичен достъп. Атакуващият трябва да разполага с права в Kubernetes за създаване на ServiceAccount и получаване на неговия токен в друго именно пространство.

Атакуващият също така трябва да има мрежов достъп до API на Consul. Поради това бюлетинът не описва атака, която всеки неавтентикиран интернет потребител може да извърши срещу произволно внедряване на Consul.

Получените привилегии биха зависели от компонента на Consul, за който атакуващият се представя. HashiCorp заявява, че атакуващият може да придобие свързаните с компонента привилегии.

HashiCorp отстранява уязвимост в сигурността на Consul-k8s

Според бюлетина HCSEC-2026-50 успешната експлоатация не предоставя непременно пълен административен достъп, като не са предоставени експлойт код или потвърдени данни за реално извършени атаки.

Ключовата настройка е global.acls.manageSystemACLs=true. HashiCorp изрично заявява, че инсталациите с изключено управление на системните ACL не са уязвими към този проблем.

Екипите трябва да проверят както инсталираната версия на Consul-k8s, така и тази конфигурационна настройка, когато определят дали средата им е засегната. Проверката единствено на версията не доказва наличие на уязвимост.

Проблемът се различава от предишни атаки срещу неправилно конфигурирани DevOps сървъри, които включваха Consul сред целевите платформи. В този случай HashiCorp идентифицира пропуск в генерираните правила за оторизация, а не просто публично достъпна услуга. И двата случая показват защо достъпността до API има значение при оценката на инфраструктурния риск.

Свързаните доклади за кражба на токени в Kubernetes и злоупотреба с разрешения също показват защо достъпът до служебни акаунти (service accounts) е критичен. За тази уязвимост обаче специалистите по киберсигурност трябва да следват конкретните предпоставки в бюлетина на HashiCorp, вместо да предполагат, че несвързана атака доказва успешна експлоатация.

HashiCorp съветва клиентите да оценят риска и да преминат към Consul-k8s 2.1.0 или 1.8.18. Компанията изказва признателност към изследователя по сигурност Elias Hasas, известен в GitHub като zer0d4y5, за докладването на уязвимостта. Бюлетинът не посочва допълнителни изисквания за почистване след обновяването.