Dynamicky sestavený Bifrost mohl bez přihlášení spustit modul z webu
Správní rozhraní AI brány Bifrost před verzí 2.0.0 přijímalo od nepřihlášeného volajícího internetovou adresu vlastního zásuvného modulu. V dynamickém sestavení mohl stažený modul běžet uvnitř procesu brány; oficiální statický obraz jej spustit neuměl, ale požadavek do vnitřní sítě poslat dokázal.
Bifrost stojí mezi aplikací a poskytovateli jazykových i obrazových modelů. Směruje požadavky, vede náklady a umí do provozu zapojit vlastní zásuvné moduly. Právě jejich načítání mělo podle záznamu CVE-2026-86242 dvě slabiny: správní rozhraní nevyžadovalo přihlášení, když provozovatel autentizaci vypnul nebo nenastavil, a stahování modulu nebránilo cestě na neveřejné adresy.
JFrog zveřejnil záznam 6. září 2026 a ohodnotil chybu známkou 8,1 z deseti. Dotčený je HTTP transport před verzí 2.0.0 na Linuxu a macOS. Záznam zároveň výslovně vyjímá předběžné vydání 2.0.0-prerelease3 a novější. Samotná chyba byla nahlášená neveřejně už 19. července a projekt opravu sloučil 3. srpna.
Statický obraz zastavil kód, nikoli síťový požadavek
Vlastní modul pro Bifrost je sdílená knihovna jazyka Go se souborovou příponou .so. Starší brána přijala jeho internetovou adresu, stáhla obsah do dočasného souboru a předala jej funkci plugin.Open. Pokud modul nabízel inicializační funkci, běžela uvnitř procesu Bifrostu a s jeho právy.
To ale neplatilo pro každou instalaci stejně. V oficiálním staticky sestaveném obrazu Dockeru dynamické načítání není dostupné. Pokus proto skončil chybou a cizí kód se nespustil. Brána už předtím soubor stáhla, takže ji šlo přimět k požadavku na adresu dostupnou jen z její sítě. Takové chybě se říká server-side request forgery neboli SSRF: server volá cíl, ke kterému se útočník zvenku sám nedostane.
Možné spuštění kódu se týkalo dynamicky sestavených binárek, které Bifrost pro vlastní moduly dokumentuje. Modul musel odpovídat operačnímu systému, architektuře, verzi Go i způsobu sestavení cílového procesu. Právě kvůli téhle podmínce uvádí záznam vysokou složitost útoku. Výzkumníci navíc přiznávají, že úplné načtení škodlivé knihovny na dynamickém sestavení v laboratoři nedokončili; hodnocení vychází z dokumentovaného chování loaderu.
Oprava oddělila přihlášení od kontroly cíle
Opravný návrh číslo 5763 přidal dvě samostatné pojistky. Když požadavek prošel jen proto, že je přihlašování vypnuté nebo nenastavené, správní rozhraní už nedovolí založit ani změnit vlastní cestu modulu. Vrátí stav 403 ještě před zápisem konfigurace. Přihlášený správce tu možnost dál má.
Druhá pojistka hlídá samotné stahování. Nový klient povolí jen HTTP a HTTPS, odmítne místní, privátní, link-local a další neveřejné adresy a kontrolu opakuje také po přesměrování. Tím zavírá i pokus, při němž veřejné jméno po první kontrole začne ukazovat dovnitř sítě. Provozovatel může výslovně povolit důvěryhodné interní úložiště modulů; seznam se nastavuje při spuštění a nelze jej měnit přes správní rozhraní.
Stabilní oprava je až ve větvi 2.0
První stabilní vydání s opravou je Bifrost HTTP 2.0.0 z 26. srpna. Poslední verze 1.6.11 vyšla 14. srpna a opravu ve svém seznamu změn nemá; záznam CVE potvrzuje, že celá řada 1.6.x zůstává dotčená. Samotný přechod na 2.0 je nekompatibilní a obsahuje databázové migrace, takže provozovatel musí projít návod k přechodu, ne pouze vyměnit značku obrazu.
Kdo vlastní moduly nepotřebuje, může podle JFrogu zůstat u oficiálního statického obrazu, který jejich spuštění neumí. Tím ale neodstraní SSRF ve starém stahovači. Do aktualizace má zapnout přihlášení do správy a nevystavovat její rozhraní nedůvěryhodné síti. Úplnou nápravou je verze 2.0.0 nebo novější.
Zdroje
- CVE-2026-86242, záznam přidělený a zveřejněný JFrogem 6. září 2026
- GHSA-7g8f-4jrf-x782, výpis téhož záznamu v databázi GitHubu
- oprava v repozitáři Bifrostu, sloučená 3. srpna 2026
- poznámky k vydání Bifrost HTTP 2.0.0 a 1.6.11