Podatności Bifrost

Bifrost rejestruje klientów MCP przez API zarządzania, a klient stdio to polecenie wraz z argumentami, które jest uruchamiane natychmiast po dodaniu klienta, bez wymaganego uzgadniania MCP. Domyślnie uwierzytelnianie jest wyłączone (governance.auth_config.is_enabled=false), więc każdy wywołujący jest traktowany jako lokalny administrator. Pojedynczy nieuwierzytelniony POST /api/mcp/client wystarcza, aby uruchomić dowolny program jako użytkownik procesu Bifrost (appuser w oficjalnym obrazie).

Palety `vtoken-minting` i `slpx` w Bifrost zawierają podatność na nieprawidłową autoryzację w przypisywaniu prowizji kanałowych. Podpisane konto może podać dowolny zarejestrowany `channel_id` podczas mintowania tokenów bez weryfikacji, czy wywołujący jest uprawniony do mintowania w imieniu tego kanału. Umożliwia to atakującemu zawyżenie zarejestrowanego wolumenu mintowania kanału i spowodowanie nieproporcjonalnego rozdzielenia płatności prowizyjnych na rzecz tego kanału podczas rozliczania prowizji.

Bifrost HTTP transport przed wersją 2.0.0 akceptuje włączony niestandardowy plugin, którego ścieżka jest URL HTTP, przez nieuwierzytelnione POST /api/plugins, gdy uwierzytelnianie zarządzania jest wyłączone (domyślnie). Ładowarka obiektów współdzielonych traktuje ścieżkę z prefiksem http jako URL do pobrania, zapisuje ciało do tymczasowego pliku .so i przekazuje do plugin.Open. Po pomyślnym otwarciu opcjonalny Init uruchamia się z dostarczoną konfiguracją jako użytkownik procesu Bifrost. Na dynamicznie linkowanych buildach jest to zdalne wykonanie kodu; na statycznie linkowanym obrazie Docker tylko SSRF.

Bifrost przed wersją 1.5.17 błędnie klasyfikuje adresy z zakresów CGNAT, 6to4, NAT64 i fec0::/10 jako publiczne. Atakujący kontrolujący adres URL multimodalnego żądania może sprawić, że brama pobierze zasoby z wewnętrznych usług, w tym metadane instancji chmury.