CVE-2026-101084: Adgangsfejl i Obots MCP-connect
Obot før v0.21.1 tjekker ikke adgangsrettigheder på /mcp-connect. Enhver logget bruger kan tilgå spærrede MCP-servere. Opdatér til v0.21.1.
Hvad er det?
Sårbarheden findes i Obot, en platform til at bygge og køre AI-agenter, der kobler sig til eksterne systemer via MCP-servere. MCP (Model Context Protocol) er en standard, der lader en AI-model kalde værktøjer og hente data fra bagvedliggende systemer. Fejlen sidder i endepunktet /mcp-connect, som ikke kontrollerer, om en bruger reelt har ret til at tilgå en given MCP-server. Enhver bruger, der er logget ind, kan derfor forbinde til en spærret MCP-server, blot hvis vedkommende kender serverens ID. Det er en klassisk fejl i adgangskontrol, hvor systemet stoler på et ID i stedet for at tjekke rettigheder, kategoriseret som CWE-639.
Hvem rammer det?
Det rammer virksomheder og organisationer, der kører Obot i en version før v0.21.1, og som har opsat MCP-servere med adgangsbegrænsning, for eksempel til økonomisystemer, CRM eller andre interne datakilder. Er MCP-serveren koblet til gemte OAuth-legitimationsoplysninger, altså gemte adgangstokens til et eksternt system, kan en uautoriseret bruger udnytte disse til at nå systemer, vedkommende ellers ikke må tilgå.
Hvad kan ske?
En bruger med lave rettigheder i Obot kan koble sig på en MCP-server, der er tiltænkt en anden afdeling eller et andet formål, og bruge den gemte OAuth-adgang til at hente og ændre data i det bagvedliggende system. I praksis kan det betyde, at en medarbejder uden adgang til for eksempel løn- eller kundedata alligevel kan læse og manipulere disse data via en fejlkonfigureret AI-agent, uden at det kræver noget udover en almindelig brugerkonto og kendskab til et server-ID.
Hvor alvorligt er det?
CVSS-scoren er 9,6 ud af 10, hvilket er kritisk. Angrebet kræver kun lave rettigheder, altså en almindelig brugerkonto, ingen brugerinteraktion og kan udføres over netværket med lav kompleksitet. Fortrolighed og integritet er sat til høj påvirkning, mens tilgængelighed ikke er berørt. Scope er markeret som ændret, hvilket betyder, at angrebet kan påvirke ressourcer uden for Obots eget system, i dette tilfælde de bagvedliggende systemer, MCP-serverne er koblet til. Der er ikke oplysninger om, at sårbarheden er udnyttet i praksis på offentliggørelsestidspunktet.
Hvad gør jeg nu?
Følgende punkter bør gennemgås, startende med det, der lukker hullet.
- Opdatér Obot til version 0.21.1 eller nyere, hvor adgangskontrollen på /mcp-connect er rettet.
- Gennemgå logs for /mcp-connect-kald for at se, om brugere har forbundet til MCP-servere, de ikke burde have adgang til.
- Rotér OAuth-legitimationsoplysninger, der er gemt på MCP-servere med følsomme data, så eventuelt kompromitterede tokens bliver ugyldige.
- Gennemgå og stram op på, hvilke brugere der har adgang til hvilke MCP-servere, og fjern unødvendige rettigheder.
- Er I i tvivl om, hvorvidt jeres opsætning har været udsat, eller mangler I ressourcer til at gennemgå logs, bør I hente hjælp udefra.
Opdatér til v0.21.1 hurtigst muligt
Vi anbefaler, at I opdaterer Obot til v0.21.1 snarest, da fejlen kræver meget lidt af en angriber og rammer fortrolighed og integritet af data i tilkoblede systemer. Det er kun forsvarligt at vente, hvis jeres Obot-installation slet ikke bruger MCP-servere med adgangsbegrænsning eller gemte legitimationsoplysninger. Har I data af følsom karakter koblet på, bør opdateringen prioriteres samme dag, den bliver tilgængelig i jeres miljø.
Tidslinje
Konkrete eksempler
AI-agent med adgang til økonomisystem
En dansk produktionsvirksomhed bruger Obot til at lade en AI-agent hente data fra virksomhedens økonomisystem via en MCP-server med gemt OAuth-adgang. En medarbejder fra lagerafdelingen, der kun skal bruge Obot til lagerstyring, gætter eller finder server-ID’et for økonomi-MCP-serveren og forbinder til den. Uden at have de nødvendige rettigheder kan medarbejderen nu hente og potentielt ændre økonomidata gennem AI-agenten.
Ofte stillede spørgsmål
Hvordan finder vi ud af, om vi er ramt?
Tjek jeres Obot-version. Er den ældre end v0.21.1, og har I opsat MCP-servere med adgangsbegrænsning, er I potentielt sårbare. Gennemgå desuden logs for /mcp-connect for uventede forbindelser.
Kan vi vente med at opdatere til weekenden?
Er MCP-serverne kun koblet til data uden følsomt indhold, kan I vente kort tid. Er der gemte OAuth-adgange til økonomi-, kunde- eller HR-systemer, bør opdateringen ske samme dag, I opdager fejlen.
Kræver angrebet adgang til vores netværk?
Nej, angrebet foregår over netværket og kræver blot, at angriberen har en gyldig brugerkonto i Obot samt kendskab til et server-ID. Der kræves ingen særlig teknisk adgang udover det.
Skal vi anmelde hændelsen, hvis vi finder tegn på misbrug?
Finder I beviser på, at nogen har udnyttet fejlen til at tilgå personoplysninger, skal I vurdere anmeldelsespligt efter databeskyttelsesreglerne og eventuelt underrette Datatilsynet inden for 72 timer.
Er alle vores MCP-servere ramt?
Kun MCP-servere, der er sat op med adgangsbegrænsning i Obot, er relevante her. Servere uden restriktioner var i forvejen tilgængelige for alle brugere, så risikoen er størst der, hvor I har forventet begrænset adgang.
Hvad gør vi, hvis vi ikke kan opdatere med det samme?
Begræns i mellemtiden, hvem der har brugerkonti i Obot, og fjern eller deaktiver MCP-servere med gemte legitimationsoplysninger til følsomme systemer, indtil opdateringen er gennemført.
CVSS-detaljer
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N
CWE-svaghedstyper
Original NVD-beskrivelse (engelsk)
obot versions before v0.21.1 fail to enforce Access Control Rules on the /mcp-connect endpoint, allowing any authenticated user to connect to restricted MCP servers if they possess the server ID. Attackers can bypass authorization checks to access and manipulate sensitive backend systems through MCP tool calls using stored OAuth credentials.
Referencer & kilder
Eksterne kilder
Brug for hjælp med jeres sikkerhed?
Vi hjælper SMV’er med at omsætte trusler som denne til konkrete handlingsplaner.