В open source AI-шлюзі Bifrost, що маршрутизує запити до більш ніж 20 провайдерів великих мовних моделей, виявлено дві вразливості, які дозволяють неавтентифікованому зловмиснику виконувати довільні команди на сервері. Найнебезпечніша з них — CVE-2026-90898 — експлуатується одним HTTP-запитом до API керування за конфігурації за замовчуванням. За даними JFrog Security Research, оцінка CVSS становить 9.8. Виправлення доступне у версії transports/v2.1.0. Операторам, які використовують Bifrost із вимкненою автентифікацією API керування (налаштування за замовчуванням), слід негайно оновитися або застосувати тимчасові рішення.
Технічні деталі вразливостей
CVE-2026-90898: виконання команд через реєстрацію MCP-клієнта
Дослідник Юваль Моравчик із JFrog виявив, що за вимкненої автентифікації API керування (параметр governance.auth_config.is_enabled за замовчуванням установлений у false) зловмисник може надіслати єдиний POST-запит на ендпоінт /api/mcp/client і зареєструвати MCP-клієнта типу stdio. Bifrost негайно запускає вказану в запиті команду від імені процесу шлюзу — ще до завершення MCP-handshake. В офіційному Docker-образі процес виконується від користувача appuser.
Уразливі всі версії Bifrost HTTP transport до 2.1.0 включно, зокрема версія 2.0.0 і лінійка 1.6.x аж до 1.6.11. Оскільки шлюз зберігає API-ключі підключених провайдерів, виконання команд у контексті процесу шлюзу потенційно дає зловмиснику доступ до цих облікових даних.
CVE-2026-86242: завантаження шкідливого плагіна по HTTP
Друга вразливість, CVE-2026-86242, була розкрита JFrog 6 вересня. За даними дослідників, оцінка CVSS — 8.1. Неавтентифікований зловмисник може зареєструвати користувацький плагін, указавши HTTP-адресу як шлях. Bifrost завантажує файл, записує його як тимчасовий розділюваний об’єкт і підвантажує через функцію plugin.Open у Go.
Вплив залежить від типу збірки: на динамічно скомпонованих збірках (необхідних для користувацьких Go-плагінів) завантажений код виконується від імені процесу шлюзу. На статично скомпонованих збірках, включно з офіційним Docker-образом, plugin.Open завершується помилкою, і вразливість зводиться до підроблення серверних запитів (SSRF). Виправлення доступне, починаючи з transports/v2.0.0.
Відмінності в пріоритеті патчів
Дві вразливості вимагають різних рішень щодо оновлення. CVE-2026-90898 усувається лише у версії transports/v2.1.0 — проміжна версія 2.0.0 усе ще вразлива. CVE-2026-86242 виправлена вже в transports/v2.0.0. При цьому для типової експлуатації на основі офіційного Docker-образу (статична компоновка) саме CVE-2026-90898 становить найбільшу загрозу: шлях до виконання довільних команд працює на цьому образі без додаткових умов. Шлях до віддаленого виконання коду через CVE-2026-86242 на тому самому образі блокується і зводиться лише до SSRF. Таким чином, оновлення до transports/v2.1.0 закриває обидві вразливості й має бути пріоритетним.
Мережева експозиція: бінарний файл і Docker
Рівень доступності API керування залежить від способу розгортання. Стандартний бінарний файл Bifrost прив’язує API керування до localhost, обмежуючи доступ локальною машиною. Офіційний Docker-образ прив’язує його до 0.0.0.0 — якщо порт опублікований, API стає доступним ззовні контейнера. Ця відмінність критично важлива під час оцінки реального ризику: контейнерні розгортання з опублікованим портом керування піддаються віддаленій експлуатації без будь-яких додаткових умов.
Контекст: третя вразливість за місяць
Обидві вразливості мають одну кореневу причину — API керування Bifrost постачається з вимкненою автентифікацією за замовчуванням. Це вже друга і третя проблеми безпеки, розкриті в проєкті менш ніж за місяць: раніше, наприкінці серпня, була виправлена непов’язана SSRF-вразливість CVE-2026-55245 (деталі щодо неї підтверджені лише вихідним новинним матеріалом; первинний бюлетень безпеки не отримано).
На момент публікації жодна з вразливостей Bifrost не внесена до каталогу CISA KEV, і незалежних свідчень активної експлуатації не виявлено. Водночас існують публічні докази концепції, а подібна вразливість ін’єкції команд в іншому AI-шлюзі LiteLLM, за даними вихідного матеріалу, була додана до каталогу CISA KEV у червні 2026 року після підтвердженої експлуатації.
Рекомендації
- Оновіть Bifrost HTTP transport до версії transports/v2.1.0 — це закриває обидві вразливості. Версія 2.0.0 усуває лише CVE-2026-86242.
- Якщо негайне оновлення неможливе — увімкніть автентифікацію API керування: встановіть
governance.auth_config.is_enabledуtrueі задайте надійні облікові дані. - Обмежте мережевий доступ до API керування: не публікуйте порт керування в недовірені мережі, особливо в Docker-розгортаннях.
- JFrog рекомендує вважати скомпрометованим будь-який екземпляр, який працював із вимкненою автентифікацією та доступним ззовні API керування. У таких випадках необхідно ротувати віртуальні ключі й API-ключі провайдерів.
- Лінійка 1.6.x аж до 1.6.11 не містить жодного з виправлень — міграція на 2.1.0 є обов’язковою.
Обидві вразливості Bifrost — наслідок архітектурного рішення постачати API керування без автентифікації за замовчуванням. Для операторів, які використовують Bifrost у контейнерних середовищах з опублікованим портом керування, єдина надійна дія — оновлення до transports/v2.1.0 з одночасною ротацією всіх ключів провайдерів, якщо екземпляр міг бути доступний ззовні.
