Две критични уязвимости в ArangoDB могат да позволят на външен атакуващ да заобиколи контрола за влизане, да прочете или промени данни в базата данни и след това да получи право за изпълнение на код от ниво root на хоста.

Проблемите засягат инсталации до версия 3.12.10.1, създавайки сериозен риск за бази данни, достъпни през интернет, и контейнерни внедрявания.

Атаката не разчита на откраднати пароли, щракване от страна на потребител или сложна верига от уязвимости. Внимателно кодирана заявка може да обърка две части на сървъра относно това дали защитен път на приложния програмен интерфейс (API) е публичен.

Подобни инциденти със заобикаляне на автентикация в корпоративни среди показват как този тип грешка може да отвори достъп до критична инфраструктура. Анализатори от Remedio идентифицираха уязвимостите, докато преглеждаха повърхността за атаки през HTTP на ArangoDB.

Remedio съобщават в доклад, споделен с Cyber Security News (CSN), че и двете грешки произтичат от това, че сървърът се доверява на предоставената от заявката информация, когато решава какво може да прави даден потребител.

Критични уязвимости в ArangoDB позволяват заобикаляне на автентикацията

Първата уязвимост се проследява като GHSA-rrgq-978q-36mq и получи оценка CVSS 3.1 от 9.8. При режима на автентикация по подразбиране само за системата в ArangoDB, пътищата, започващи с /_, са предназначени да изискват влизане, докато останалите пътища се третират като публични приложни маршрути.

Изследователите установиха, че проверката за автентикация анализира суровия URL адрес, но кодовете за маршрутизация по-късно интерпретират декодирана версия.

Замяната на долната черта в /_api с нейната URL-кодирана форма %5f кара първия компонент да вижда път, който изглежда публичен, докато рутерът достига до ограничения API крайен пункт. Това малко разминаване в парсването е достатъчно за заобикаляне на входа за влизане.

Заявка без идентификационни данни може да достигне до защитени действия в базата данни, позволявайки административен достъп без пароли в колекции и бази данни. Изследователите демонстрираха извличане на хеша на паролата за root акаунта, който използва един кръг SHA-256 и 32-битов salt.

Настройката на задачи позволява изпълнение от ниво Root

Вторият проблем, GHSA-rvhw-4hpw-9vrx, засяга HTTP интерфейса на ArangoDB за планиране на фонови задачи на JavaScript.

Той има CVSS 3.1 оценка от 9.9, тъй като потребител с право за запис в базата данни може да зададе полето isSystem в заявката на true и да принуди дадена задача да влезе във вътрешния, привилегирован контекст на изпълнение на сървъра.

Обикновено този контекст е запазен за самия сървър. Вътрешният JavaScript API проверява дали субектът е наистина вътрешен, преди да позволи системни задачи, но HTTP манипулаторът не е приложил същата защита.

Резултатът е управлявана от клиента булева стойност, действаща като граница между работата в изолирана среда и привилегиите на ниво хост. След като дадена задача се изпълни в този контекст, тя може да чете или записва файлове на хоста и да прави изходящи уеб заявки.

В официалното изображение за контейнери процесът arangod се изпълнява като root, така че достъпът до файлове може да разкрие тайни като /etc/shadow, приватни ключове за TLS, материали за подписване на клъстери или променливи на средата, съдържащи root паролата.

Разрешението за запис на файлове също създава практически път към отдалечено изпълнение на код като root. Киберпрестъпник би могъл да постави авторизиран SSH ключ, да промени планирана задача или да модифицира сервизен файл, който да се изпълни по-късно.

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

Уязвимостите могат да бъдат комбинирани във верига: първата грешка може да разкрие хеша на root паролата, а втората може да използва автентикирания достъп за запис в базата данни, за да излезе в привилегированата среда за задачи.

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

ArangoDB получи докладите на 23 август 2026 г. и пусна корекции на 31 август във версия 3.12.11. Официалните препоръки бяха публикувани на 6 септември, докато CVE идентификаторите все още са чакащи.

Организациите, използващи версия 3.12.10.1 или по-ранна, трябва незабавно да отстранят уязвимостта чрез обновяване, да ограничат достъпа до базата данни само до доверени мрежи, да подменят потенциално изложените данни за достъп и да разследват неочаквано създаване на задачи или API активност.

По-широкият извод е прост: защитените компоненти все още могат да се провалят, когато interpret-ват една и съща заявка по различен начин. Разработчиците трябва да нормализират и авторизират заявките еднократно, да прилагат едно и също решение за всички манипулатори и никога да не позволяват на входни данни от клиента да изискват системни привилегии.

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

Поддържайте вашия SOC център информиран за активен зловреден код и фишинг в рамките на 24 часа от появата им. Изпробвайте ANYRUN, за да предотвратите инциденти с ранно откриване.