CERT/CC опублікував бюлетень VU#645818, у якому описано вразливість обходу автентифікації в консольному API пошуково-індексаційного рушія Xerj — відкритого рішення, орієнтованого на AI-агентів і сумісного з Elasticsearch API. Вразливість CVE-2026-97406 дає змогу зловмиснику, який має чинний API-токен, створювати незалежні «дочірні» облікові дані з тим самим рівнем доступу, оминаючи вимогу passkey-автентифікації. Критично важлива деталь: відкликання скомпрометованого батьківського токена не впливає на створених із нього нащадків. Станом на момент публікації бюлетеня офіційного патча немає, а координаторам CERT/CC не вдалося зв’язатися з розробником. Організаціям, що використовують Xerj, слід негайно провести аудит виданих API-токенів і обмежити доступ до консольного API.
Технічна суть вразливості
Згідно з бюлетенем CERT/CC, архітектура Xerj передбачає, що випуск нових API-токенів має авторизовуватися виключно сесією, підтвердженою через passkey. Однак реалізація перетворює як звичайні браузерні сесії, так і bearer-токени API в єдиний узагальнений об’єкт AuthSession. Обробник створення токенів приймає цей об’єкт без перевірки того, чи була сесія автентифікована саме через passkey.
Вразлива площа атаки — вбудований консольний бекенд, який, згідно з архітектурною документацією проєкту, монтується за шляхом /_xerj-console/api/v1/*. При цьому документація щодо авторизації стверджує, що створювати ключі з обмеженою областю дії може лише суперкористувач — але вразливість дає змогу обійти це обмеження.
Ключові характеристики вразливості:
- Передумова: зловмисник має отримати або перехопити чинний Xerj API-токен
- Механізм: прямий виклик ендпоінта створення токенів через bearer-автентифікацію без passkey-підтвердження
- Результат: створення незалежних облікових даних з правами, ідентичними правам вихідного токена
- Персистентність: платформа не реалізує ієрархічну логіку відкликання — дочірні токени залишаються активними після відкликання батьківського
Оцінка CVSS для CVE-2026-97406 у доступних матеріалах не наводиться. Діапазон уражених версій також не встановлено.
Сценарій ескалації до повного захоплення інстансу
За даними CERT/CC, найбільшу небезпеку вразливість становить у разі компрометації токена, що належить власнику облікового запису Xerj. У цьому випадку описано таку ланку атаки: зловмисник створює дочірній токен з повними адміністративними правами, потім використовує його для випуску запрошення в новий обліковий запис, активує запрошення у власному браузері та реєструє повністю незалежний passkey під своїм контролем. Результат — постійний доступ до інстансу Xerj та його індексів даних, який неможливо усунути відкликанням початково скомпрометованого токена.
У бюлетені це характеризується як повний обхід багатофакторних контролів, оскільки вимога passkey — центральний елемент захисту — повністю нейтралізується.
Оцінка впливу
Xerj позиціонується як пошуковий рушій для AI-агентів, що індексує локальні дані. Компрометація інстансу потенційно відкриває доступ до всіх проіндексованих даних — зокрема до вихідного коду, документації та інших матеріалів, які AI-агенти використовують у роботі. Для організацій, що інтегрували Xerj у робочі процеси розробки з використанням AI, наслідки можуть включати витік інтелектуальної власності та компрометацію ланцюга постачання даних для AI-моделей.
Свідчень активної експлуатації вразливості в реальних атаках у доступних матеріалах не виявлено. Атрибуція до конкретних угруповань або кампаній також відсутня.
Статус виправлення та рекомендації
CERT/CC повідомляє, що зв’язатися з розробником для скоординованого розкриття не вдалося, і офіційний патч на дату публікації бюлетеня (20 жовтня 2026 року) відсутній. На сторінці релізів проєкту опубліковано версію v1.0.0-rc.96, однак в описі релізу згадки про виправлення CVE-2026-97406 не виявлено. Це не виключає наявності виправлення, але й не підтверджує його.
До появи підтвердженого патча рекомендується:
- Обмежити мережевий доступ до консольного API (
/_xerj-console/api/v1/*) — дозволити підключення лише з довірених мереж або повністю закрити ендпоінт, якщо консоллю не користуються - Провести аудит усіх виданих API-токенів — виявити токени, створені через API (а не через passkey-сесію), і відкликати як їх, так і всі потенційно породжені ними дочірні облікові дані
- Перевірити історію запрошень і реєстрації passkey — будь-яке запрошення або реєстрація нового passkey, що відбулися після створення API-токена, мають розглядатися як підозрілі
- Налаштувати моніторинг — відстежувати звернення до ендпоінта створення токенів і подальші операції випуску запрошень або реєстрації passkey, оскільки саме така послідовність дій є характерною для описаної ланки атаки
- Відстежувати оновлення в офіційному репозиторії Xerj і не вважати оновлення виправленням CVE-2026-97406, доки це явно не підтверджено в примітках до релізу
Принципово важливо розуміти, що просте відкликання скомпрометованого токена не є достатнім заходом реагування. Через відсутність ієрархічної логіки відкликання всі дочірні токени, створені до моменту виявлення, залишаються чинними. Реагування на інцидент має включати повну ротацію всіх токенів інстансу та ревізію зареєстрованих passkey.
