В открытом шлюзе искусственного интеллекта Bifrost обнаружена уязвимость CVE-2026-90898, позволяющая без учётных данных выполнять произвольные команды на сервере. Bifrost перенаправляет запросы более чем 20 поставщикам больших языковых моделей, поэтому захват шлюза способен открыть доступ сразу к нескольким внешним сервисам. Для атаки достаточно одного HTTP-запроса. Уязвимость получила 9,8 балла по шкале CVSS; ей подвержены все версии HTTP-транспорта Bifrost до transports/v2.1.0, если аутентификация интерфейса управления отключена. Именно так продукт настроен по умолчанию.
Ошибку нашёл Юваль Моравчик (Yuval Moravchick) из JFrog Security Research. Злоумышленник может отправить неаутентифицированный POST-запрос к конечной точке /api/mcp/client и зарегистрировать MCP-клиент типа stdio. Bifrost немедленно запускает указанную в запросе команду, не дожидаясь MCP-рукопожатия и не проверяя полномочия отправителя. Команда получает права пользователя, от имени которого работает шлюз; в официальном Docker-образе это appuser.
Последствия выходят за рамки захвата одного процесса. Bifrost хранит API-ключи всех подключённых провайдеров, виртуальные ключи самого шлюза и другие секреты, доступные его рабочему процессу. Выполнив команду с правами пользователя Bifrost, атакующий может прочитать эти данные и затем обращаться к моделям за счёт владельца инфраструктуры. Поэтому JFrog советует считать скомпрометированным любой экземпляр, у которого одновременно были отключены аутентификация управления и сетевые ограничения на доступ к management API.
Степень опасности зависит от способа установки. Обычный исполняемый файл Bifrost привязывает интерфейс управления к localhost, ограничивая доступ локальной машиной. Официальный Docker-образ слушает 0.0.0.0. Если порт контейнера опубликован, management API может оказаться доступным извне. Рабочая комбинация для удалённой атаки проста: опубликованный управляющий порт, отсутствие аутентификации и возможность обратиться к нему из недоверенной сети.
Исправление выпущено в transports/v2.1.0. После обновления попытка без авторизации зарегистрировать stdio-клиент MCP получает ответ HTTP 403. Если установить новую версию сразу нельзя, следует задать governance.auth_config.is_enabled равным true, использовать стойкие учётные данные и закрыть управляющий интерфейс от недоверенных сетей. На ранее доступных экземплярах требуется сменить виртуальные ключи Bifrost и API-ключи провайдеров: простое обновление не устраняет уже состоявшуюся утечку.
Акшай Део (Akshay Deo), технический директор и сооснователь компании Maxim, разработавшей Bifrost, в заявлении для The Hacker News оспорил критическую оценку. По позиции Maxim, эксплуатация возможна лишь тогда, когда оператор одновременно открыл management-интерфейс недоверенной сети и не настроил аутентификацию. Компания заявляет, что документированная конфигурация по умолчанию предполагает размещение шлюза в частной сети, а потому считает практическую серьёзность ошибки низкой. Maxim обсуждает с JFrog, присвоившей CVE, пересмотр рейтинга. Получилась редкая, но вполне предметная развилка: JFrog и система CVE оценивают брешь в 9,8 балла, Maxim называет её малозначимой при штатном развёртывании.
С версиями есть неприятная ловушка. Все выпуски до 2.0.0 содержат и ошибку MCP, и более раннюю уязвимость подключаемых модулей; ветки 1.6.x–1.6.11 не имеют ни одного из двух исправлений. Версия transports/v2.0.0 закрывает брешь с пользовательскими плагинами, но всё ещё уязвима перед CVE-2026-90898. Только transports/v2.1.0 запрещает неавторизованную регистрацию stdio-клиента MCP. Обновление лишь до 2.0.0 оставляет возможность выполнить команду одним запросом.
Вторую связанную ошибку обнаружил участник той же исследовательской группы Ор Пелес (Or Peles). Уязвимость CVE-2026-86242, раскрытая 6 сентября 2026 года, получила 8,1 балла CVSS и была исправлена в transports/v2.0.0. Неаутентифицированный пользователь мог зарегистрировать собственный плагин, указав вместо локального пути HTTP-адрес. Bifrost загружал удалённый файл, сохранял его как временный разделяемый объект и передавал функции Go . В динамически скомпонованных сборках вредоносный модуль успешно загружался, а его код запускался с правами процесса шлюза.
Для пользовательских Go-плагинов Bifrost нужны динамически скомпонованные сборки, однако официальный Docker-образ собран статически. В таких экземплярах завершается ошибкой, поэтому произвольный код плагина не исполняется; остаётся возможность серверной подделки запросов, то есть SSRF. Общая причина у CVE-2026-86242 и CVE-2026-90898 одна: management API поставляется с отключённой аутентификацией. В первом случае это открывало регистрацию удалённого плагина, во втором — stdio-клиента MCP с немедленным запуском заданной команды.
Эти находки стали второй и третьей проблемами безопасности Bifrost, раскрытыми менее чем за месяц. Им предшествовала отдельная SSRF-уязвимость CVE-2026-55245, исправленная в конце августа 2026 года. Контекст шире одного проекта: в апреле 2026 года исследователи описали дефект конструкции транспорта MCP STDIO, затрагивающий официальные SDK компании Anthropic. В шлюзе LiteLLM обнаруживалась похожая инъекция команд; её активно эксплуатировали, и в июне 2026 года Агентство кибербезопасности и защиты инфраструктуры США CISA внесло брешь в каталог Known Exploited Vulnerabilities (KEV). На момент публикации ни CVE-2026-90898, ни CVE-2026-86242 в каталоге KEV не числились.[/final]
Изображение носит иллюстративный характер
Ошибку нашёл Юваль Моравчик (Yuval Moravchick) из JFrog Security Research. Злоумышленник может отправить неаутентифицированный POST-запрос к конечной точке /api/mcp/client и зарегистрировать MCP-клиент типа stdio. Bifrost немедленно запускает указанную в запросе команду, не дожидаясь MCP-рукопожатия и не проверяя полномочия отправителя. Команда получает права пользователя, от имени которого работает шлюз; в официальном Docker-образе это appuser.
Последствия выходят за рамки захвата одного процесса. Bifrost хранит API-ключи всех подключённых провайдеров, виртуальные ключи самого шлюза и другие секреты, доступные его рабочему процессу. Выполнив команду с правами пользователя Bifrost, атакующий может прочитать эти данные и затем обращаться к моделям за счёт владельца инфраструктуры. Поэтому JFrog советует считать скомпрометированным любой экземпляр, у которого одновременно были отключены аутентификация управления и сетевые ограничения на доступ к management API.
Степень опасности зависит от способа установки. Обычный исполняемый файл Bifrost привязывает интерфейс управления к localhost, ограничивая доступ локальной машиной. Официальный Docker-образ слушает 0.0.0.0. Если порт контейнера опубликован, management API может оказаться доступным извне. Рабочая комбинация для удалённой атаки проста: опубликованный управляющий порт, отсутствие аутентификации и возможность обратиться к нему из недоверенной сети.
Исправление выпущено в transports/v2.1.0. После обновления попытка без авторизации зарегистрировать stdio-клиент MCP получает ответ HTTP 403. Если установить новую версию сразу нельзя, следует задать governance.auth_config.is_enabled равным true, использовать стойкие учётные данные и закрыть управляющий интерфейс от недоверенных сетей. На ранее доступных экземплярах требуется сменить виртуальные ключи Bifrost и API-ключи провайдеров: простое обновление не устраняет уже состоявшуюся утечку.
Акшай Део (Akshay Deo), технический директор и сооснователь компании Maxim, разработавшей Bifrost, в заявлении для The Hacker News оспорил критическую оценку. По позиции Maxim, эксплуатация возможна лишь тогда, когда оператор одновременно открыл management-интерфейс недоверенной сети и не настроил аутентификацию. Компания заявляет, что документированная конфигурация по умолчанию предполагает размещение шлюза в частной сети, а потому считает практическую серьёзность ошибки низкой. Maxim обсуждает с JFrog, присвоившей CVE, пересмотр рейтинга. Получилась редкая, но вполне предметная развилка: JFrog и система CVE оценивают брешь в 9,8 балла, Maxim называет её малозначимой при штатном развёртывании.
С версиями есть неприятная ловушка. Все выпуски до 2.0.0 содержат и ошибку MCP, и более раннюю уязвимость подключаемых модулей; ветки 1.6.x–1.6.11 не имеют ни одного из двух исправлений. Версия transports/v2.0.0 закрывает брешь с пользовательскими плагинами, но всё ещё уязвима перед CVE-2026-90898. Только transports/v2.1.0 запрещает неавторизованную регистрацию stdio-клиента MCP. Обновление лишь до 2.0.0 оставляет возможность выполнить команду одним запросом.
Вторую связанную ошибку обнаружил участник той же исследовательской группы Ор Пелес (Or Peles). Уязвимость CVE-2026-86242, раскрытая 6 сентября 2026 года, получила 8,1 балла CVSS и была исправлена в transports/v2.0.0. Неаутентифицированный пользователь мог зарегистрировать собственный плагин, указав вместо локального пути HTTP-адрес. Bifrost загружал удалённый файл, сохранял его как временный разделяемый объект и передавал функции Go . В динамически скомпонованных сборках вредоносный модуль успешно загружался, а его код запускался с правами процесса шлюза.
Для пользовательских Go-плагинов Bifrost нужны динамически скомпонованные сборки, однако официальный Docker-образ собран статически. В таких экземплярах завершается ошибкой, поэтому произвольный код плагина не исполняется; остаётся возможность серверной подделки запросов, то есть SSRF. Общая причина у CVE-2026-86242 и CVE-2026-90898 одна: management API поставляется с отключённой аутентификацией. В первом случае это открывало регистрацию удалённого плагина, во втором — stdio-клиента MCP с немедленным запуском заданной команды.
Эти находки стали второй и третьей проблемами безопасности Bifrost, раскрытыми менее чем за месяц. Им предшествовала отдельная SSRF-уязвимость CVE-2026-55245, исправленная в конце августа 2026 года. Контекст шире одного проекта: в апреле 2026 года исследователи описали дефект конструкции транспорта MCP STDIO, затрагивающий официальные SDK компании Anthropic. В шлюзе LiteLLM обнаруживалась похожая инъекция команд; её активно эксплуатировали, и в июне 2026 года Агентство кибербезопасности и защиты инфраструктуры США CISA внесло брешь в каталог Known Exploited Vulnerabilities (KEV). На момент публикации ни CVE-2026-90898, ни CVE-2026-86242 в каталоге KEV не числились.[/final]
