Ett oautentiserat POST-anrop till Bifrosts Management API startade ett kommando som gateway-användaren

Den 14 september 2026 publicerade JFrog Security Research CVE-2026-90898, en kommandoexekveringssårbarhet i Bifrost — den AI-gateway med öppen källkod som underhålls av Maxim — och bedömde den till 9,8 av 10. Attacken var en enda HTTP-förfrågan. En oautentiserad POST /api/mcp/client registrerar en stdio-MCP-klient, som Bifrost tolkar som ett programnamn plus en argumentlista och startar omedelbart, före någon MCP-handskakning, som användaren som kör gatewayen; i den officiella avbilden är den användaren appuser. En gateway är också där en operatörs leverantörsnycklar och virtuella nycklar förvaras, så en process som körs där når autentiseringsuppgifter. Det som gjorde förfrågan anonym var en medföljande standardinställning: governance.auth_config.is_enabled är false, och, med JFrog:s formulering, ”avstängd autentisering innebär att varje anropare är lokal administratör”. Ingen citerad källa rapporterar att sårbarheten någonsin har utnyttjats. Postens egna källor, allvarlighetsgrad och bedömning av tillförlitlighet finns i AI-incidentarkivet, tillsammans med de andra dokumenterade AI-gateway- och MCP-sårbarheterna det senaste året.

Bifrost är en enda tjänst som ligger mellan en applikation och de språkmodeller den anropar. Dess repository beskriver den som en gateway med öppen källkod och Apache-2.0-licens som "förenar åtkomst till 23+ leverantörer ... genom ett enda OpenAI-kompatibelt API", med MCP-proxying, virtuella nycklar, budgetar och lastbalansering per leverantör bland sina funktioner, och den hade cirka 9 150 GitHub-stjärnor den 28 oktober 2026. Den kombinationen är hela anledningen till att ett shell på just den här värden är värt en kritisk poäng: processen som dirigerar begäranden är också processen som innehar autentiseringsuppgifterna för varje uppströmsmål den dirigerar till. Hacker News, som rapporterade om bristen den 22 september, uttryckte konsekvensen rakt ut – eftersom gatewayen lagrar API-nycklar för varje ansluten leverantör ger körning av kommandon på gatewayprocessen angriparen åtkomst till dessa autentiseringsuppgifter.

Hela attacken var en enda POST

JFrogs säkerhetsmeddelande, publicerat under referens JFSA-2026-001686326, beskriver en endpoint som finns för att låta en administratör lägga till en MCP-server. En stdio-klient i MCP-specifikationen är inte en URL; det är ett kommando med tillhörande argument, som värdprogrammet förväntas starta. Bifrost tar emot den konfigurationen via management-API:et och startar programmet så snart klienten har lagts till. Ingen kapabilitetsförhandling, ingen kontroll av serveridentitet och ingen handskakning behöver lyckas först — meddelandet säger uttryckligen att det inte är handskakningen som startar processen.

Konceptbeviset i rådgivningen är en kort JSON-body som postas till en gateway där autentiseringen lämnats på standardinställningen. Den registrerar en klient vars kommando är /bin/sh och vars argument skriver en markörfil, och läser sedan tillbaka markören. JFrog lägger till en operativ detalj som är viktig vid incidenthantering: HTTP-begäran kan timea ut medan Bifrost väntar på en handskakning som aldrig kommer, och en timeout i loggarna betyder inte att kommandot misslyckades med att starta. Processen kör redan vid det laget.

CVE-posten, som tilldelats av JFrog i egenskap av CVE Numbering Authority, kopplar defekten till CWE-306, saknad autentisering för en kritisk funktion, och CWE-284, felaktig åtkomstkontroll, och namnger de två filer som innehåller hanteraren och dess middleware: transports/bifrost-http/handlers/mcp.go och transports/bifrost-http/handlers/middlewares.go. Den berörda modulen är github.com/maximhq/bifrost/transports, på Linux och macOS, för alla versioner under 2.1.0.

Standardinställningen som gjorde begäran anonym

Inget av det skulle gå att utnyttja utan ett andra villkor, och det andra villkoret är produktens egen standardinställning. Bifrosts middleware för hanteringsautentisering styrs av governance.auth_config.is_enabled, som levereras som false. När den är avstängd behandlar middleware varje anropare som lokal administratör — säkerhetsbulletinens egen sammanfattning är att avstängd autentisering innebär att varje anropare är lokal admin — så kontrollen som skulle ha stoppat begäran ingick aldrig i kedjan.

Åtgärden, pull request #6757, slogs samman i projektet den 2 september 2026, tolv dagar innan CVE:n publicerades och sex dagar innan utgåvan som innehåller den. Dess beskrivning är ovanligt öppenhjärtig om problemets form: pull requesten stänger två primitiver för oautentiserad åtkomst i samma registrerings-API, inte en. Den första är stdio-klienten. Den andra är en http- eller sse-MCP-klient riktad mot en loopback- eller privatnätverksadress, vilket pull requesten kallar en SSRF-primitiv mot interna tjänster, "inklusive molnmetadataändpunkten 169.254.169.254". Båda avvisas nu med HTTP 403 när förfrågan når hanteraren utan en genuin autentiseringskontroll. Autentiserade administratörer behåller båda funktionerna, och operatörer kan fortfarande tillhandahålla stdio-klienter via config.json.

Den där andra primitiven förekommer inte i CVE-texten. Den finns i patchen, och det är anledningen till att åtgärden är en spärr snarare än en borttagning: funktionen var aldrig buggen. Att behandla en oautentiserad anropare som administratör var det.

Var management-API:t faktiskt lyssnade

Reachability är den del av posten som källorna beskriver mest konsekvent och mäter minst. JFrogs rådgivning anger standardbinärens standardvärde som localhost:8080, vilket begränsar en angripare till värden själv. Samma teams rådgivning för den kompletterande sårbarheten anger att den officiella Docker-avbildningen i stället binder till 0.0.0.0, och The Hacker News upprepar det: avbildningen gör management-API:et nåbart utanför containern om porten publiceras. Bifrosts egen README-snabbstart kör "docker run -p 8080:8080 maximhq/bifrost", och Dockers -p publicerar en containerport på alla värdgränssnitt om ingen adress anges. GitHub-rådgivningen för sårbarheten anger att den rapporterade sökvägen verifierades mot den publicerade avbildningen maximhq/bifrost:latest, där en oautentiserad begäran startade /bin/sh och skrev en markör som appuser.

Det som ingen källa tillhandahåller är en siffra. Det finns inget antal internetexponerade Bifrost-instanser, inget skanningsresultat, ingen telemetri och inget offer. Redogörelsen innehåller ingen verklig skada, och den frånvaron är ett faktum om rapporteringen snarare än en lugnande försäkran — sårbarhetsklassen är bara farlig där två villkor sammanfaller, en exponerad lyssnare och en orörd standardinställning, och ingen har publicerat hur ofta de sammanföll.

En slutpunkt, två brister, en grundorsak

Åtta dagar före MCP-säkerhetsmeddelandet, den 6 september 2026, publicerade samma forskningsteam CVE-2026-86242, en andra oautentiserad väg in i samma process. Den upptäcktes av Or Peles och fick betyget 8.1, och utnyttjar POST /api/plugins: Bifrost accepterar ett aktiverat anpassat plugin vars sökväg är en HTTP-URL, shared-object-laddaren behandlar en sökväg med http-prefix som en nedladdning, skriver nedladdningens innehåll till en tillfällig .so-fil och överlämnar filen till Go:s plugin.Open. Om laddningen lyckas körs en valfri Init-funktion omedelbart med angriparens konfiguration, som gateway-användaren.

Byggvarianten avgör vad en angripare får. På de dynamiskt länkade byggen som projektet dokumenterar för anpassade Go-plugin-program förväntas laddningen lyckas, vilket rådgivningen kallar oautentiserad fjärrkodkörning. På den publicerade statiskt länkade Docker-avbildningen misslyckas plugin.Open med "Dynamic loading not supported", så samma begäran degraderas till server-side request forgery. En laddningsbar plugin måste också matcha värdens Go-version, operativsystem, arkitektur och länkning, vilket är en verklig begränsning snarare än en formalitet. Rättningen är transports/v2.0.0, via pull request #5763, och det påverkade intervallet är allt under det.

Fällan är utgivningsordningen. v2.0.0 åtgärdar plugin-sökvägen och åtgärdar inte MCP-sökvägen — The Hacker News säger det uttryckligen, och JFrog:s MCP-rådgivning bekräftar att v2.0.0 fortfarande tillåter den oautentiserade stdio-registreringen. En operatör som patchade snabbt efter rådgivningen den 6 september var, enbart på den punkten, fortfarande exponerad tills transports/v2.1.0 släpptes den 8 september. Båda bristerna kan reduceras till samma mening i båda rådgivningarna och i leverantörens egen pull request: autentisering inaktiverad är standard.

Vad källorna fastställer, och vad de inte fastställer

Mekanismen, versionsintervallet, rättningen och tillskrivningen är samstämmiga mellan säkerhetsmeddelandet, CVE-posten som JFrog tilldelade, projektets egen pull request och versionsinformation samt The Hacker News. Den återstående oenigheten gäller allvarlighetsgraden, och den är verklig.

9,8 är JFrogs poäng i egenskap av tilldelande CNA, och det är poängen som NVD för — NVD-posten anger reefs@jfrog.com som mätvärdeskälla och visar, per den 28 oktober 2026, fortfarande posten med statusen "Awaiting Analysis", vilket innebär att NVD har publicerat tilldelarens vektor i stället för sin egen analys av den. CISA Coordinators SSVC-bedömning som är kopplad till samma post, med tidsstämpel 14 september 2026, anger exploitation "none", automatable "yes" och technical impact "total". FIRST:s EPSS-modell satte sannolikheten för exploatering under de kommande 30 dagarna till 2,3 procent den 27 oktober 2026, i 83:e percentilen bland alla bedömda CVE:er, och varken denna CVE eller CVE-2026-86242 finns med i CISA Known Exploited Vulnerabilities-katalogen daterad 27 oktober 2026.

Mot detta bestrider Maxim betyget. I ett uttalande till The Hacker News sade Akshay Deo, företagets teknikchef och medgrundare, att den praktiska risken är lägre än den kritiska poängen antyder, eftersom utnyttjande kräver att hanteringsgränssnittet är nåbart från ett otillförlitligt nätverk och att operatören har lämnat autentiseringen oinställd; den förvalda och dokumenterade distributionen, sade han, placerar gatewayen i ett privat nätverk. The Hacker News rapporterar att Maxim anser att sårbarheten har låg allvarlighetsgrad och arbetar med JFrog, som tilldelade CVE, för att revidera bedömningen. Det uttalandet förekommer i den enda publikationen; ingen andra publikation som citerar Maxims ståndpunkt hittades, och ingen revidering hade publicerats per den 28 oktober 2026 — CVE-posten uppdaterades senast den 14 september och NVD-posten den 18 september, båda fortfarande på 9.8.

Ytterligare två luckor förtjänar att nämnas i stället för att slätas över. Projektets GitHub-säkerhetsmeddelanden, publicerade den 23 september 2026 och med JFrogs forskare angiven som rapportör, anger fortfarande 9.8 för MCP-felet och 8.1 för plugin-felet, utan några tecken på den revision som Maxim beskrev. Och de påverkade intervallen i dessa meddelanden är skrivna mot Go-modulversioner – under 1.5.27 och under 1.6.3 – i stället för de release-taggar för transports som JFrogs meddelanden använder, så en operatör som jämför det ena dokumentet med det andra måste stämma av två numreringsscheman innan hen kan avgöra om ett bygge är påverkat.

Vad som ändrades, och vad operatörerna fick veta att de skulle göra

Kronologin löper baklänges från offentliggörandet, vilket är den minst intuitiva delen av historiken. Pull request #6757 mergades den 2 september 2026. transports/v2.1.0, utgåvan som rådgivningen anger som den första som innehåller rättningen, publicerades den 8 september – sex dagar innan CVE-2026-90898 publicerades den 14 september. Projektets plugin-rättelse föregick dess egen rådgivning på samma sätt: transports/v2.0.0 släpptes den 26 augusti, elva dagar före CVE:n den 6 september. Operatörer som följer utgåvor i stället för flöden hade patcharna innan de hade varningarna.

Det uppgraderingen ger är snävt och specifikt. I 2.1.0 och senare returnerar en oautentiserad stdio-registrering 403 och kommandot startar inte; autentiserade administratörer behåller möjligheten, och provisionering via config.json fungerar fortfarande. Säkerhetsrådgivningens tillfälliga lösning för den som inte kan flytta är att sätta governance.auth_config.is_enabled till true, använda starka administratörsautentiseringsuppgifter och hålla hanteringslyssnaren borta från ej betrodda nätverk. JFrogs instruktion för instanser som kördes exponerade med autentisering inaktiverad är inte att utreda och hoppas: behandla dem som komprometterade och rotera virtuella nycklar och leverantörsautentiseringsuppgifter.

Versionsaritmetiken är den del som lättast misstolkas. v2.0.0 åtgärdar inte den här bristen. Inte heller 1.6.x-serien fram till 1.6.11 innehåller rättelsen, och projektets nyaste tagg i 1.6-serien är transports/v1.6.11, publicerad den 14 augusti 2026, och det finns ingen 1.7-linje i repositoryt den 28 oktober 2026 – så det finns ingen patchad utgåva inom den serien, och en operatör på 1.6.x måste gå över till 2.1.0 eller senare i stället för att vänta på en backport. Den aktuella utgivningslinjen ligger långt förbi den punkten: transports/v2.3.2 publicerades den 20 oktober 2026.

Två saker hände efter publiceringen som en försvarare kan dra nytta av. Projektets GitHub-säkerhetsrådgivningar – GHSA-86gf-xh3g-rvxq för MCP-sårbarheten med allvarlighetsgraden kritisk och GHSA-2qp8-4xgm-fw6g för plugin-sårbarheten med allvarlighetsgraden hög – publicerades den 23 september 2026, vilket gav beroende- och rådgivningsflödena en andra identifierare att matcha mot. Och den 13 oktober 2026 sammanfogades en detektionsmall för CVE-2026-90898 i det publika nuclei-templates-repositoriet, vilket innebär att kontrollen för ett försök till oautentiserad registrering nu är något som en skanningspipeline kan köra i stället för något som varje team måste skriva.

Det som fortfarande är öppet är allvarlighetsgraden, och den kommer att avgöras – eller inte – av de två organisationer som fortfarande diskuterar den. Maxims ståndpunkt, enligt rapporteringen, är att 9,8 överdriver en sårbarhet som för att spela roll kräver en exponerad lyssnare och en standardinställning som inte är satt – ett påstående som i princip går att testa men som inte har testats offentligt, eftersom ingen har publicerat hur många driftsättningar som uppfyllde de två villkoren. JFrogs ståndpunkt är den poäng som företaget tilldelade i rollen som CNA, och som fortfarande står kvar i CVE-posten och i NVD. Till dess att någon av dem publicerar en revidering är den operativa tolkningen densamma oavsett: sårbarheten är verklig och verifierades från början till slut på den publicerade containeravbildningen, rättelsen släpptes före varningen, 1.6-serien har ingen rättelse alls, och varje instans som kördes med autentisering inaktiverad på en nåbar lyssnare bör behandlas som en incident med autentiseringsuppgifter snarare än som en patch att schemalägga.