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.
