CVE-2026-101065: Kritisk hul i Obot AI-platformens standardopsætning
Standardopsætningen af Obot giver fuld administratoradgang uden login til alle, der kan nå port 8080. Slå autentificering til nu.
Hvad er det?
CVE-2026-101065 rammer Obot, en open source-platform til AI-agenter og såkaldte MCP-servere (Model Context Protocol, en standard til at koble AI-agenter til værktøjer og data). Fejlen ligger i den quickstart-kommando til Docker, som Obots egen dokumentation anbefaler. Kommandoen starter containeren på adressen 0.0.0.0:8080, altså tilgængelig fra hele netværket, uden at kræve login. Når autentificering er slået fra, mapper Obot automatisk enhver forespørgsel til en indbygget bruger kaldet ‘nobody’, som har både Owner- og Admin-rettigheder. Enhver, der kan sende en forespørgsel til den åbne port, får dermed fuld administratoradgang til Obots API og brugerflade, uden at skulle logge ind eller gætte en adgangskode.
Hvem rammer det?
Det rammer virksomheder og kommuner, der har sat Obot op via den dokumenterede Docker quickstart-kommando i alle versioner til og med commit d7e6970. Det gælder især installationer, hvor porten 8080 er eksponeret mod internettet eller mod et internt netværk, som ikke er fuldt tillid til. Hvis miljøvariablen OBOT_SERVER_ENABLE_AUTHENTICATION ikke er sat til true, er systemet sårbart uanset om det kører på egen server, i sky eller lokalt hos en it-afdeling.
Hvad kan ske?
En angriber med adgang til porten får administratorrettigheder i Obot og kan registrere og starte sine egne MCP-servere inde i platformen. Fordi quickstart-opsætningen også monterer /var/run/docker.sock ind i containeren, får angriberens MCP-server adgang til værtsmaskinens Docker-styring. I praksis betyder det, at en angriber kan starte nye containere, læse og ændre data i eksisterende containere og i mange tilfælde opnå fuld kontrol over den server, Obot kører på. For en dansk virksomhed kan det ende med tab af forretningsdata, installation af skadelig kode eller at serveren bruges som springbræt videre ind i det interne netværk.
Hvor alvorligt er det?
CVSS-score er 9,8 ud af 10, kritisk. Angrebet kræver ikke login, ingen brugerhandling og kan udføres over netværket med lav teknisk kompleksitet. Der kræves ingen forudgående adgang eller viden om systemet, kun at man kan sende en forespørgsel til den åbne port. Der er ikke oplyst tilfælde af aktiv udnyttelse på offentliggørelsestidspunktet, men fordi svagheden ligger i den anbefalede standardopsætning, må man forvente, at mange installationer er sårbare uden at vide det.
Hvad gør jeg nu?
Løsningen kræver ingen ny softwareversion, kun en konfigurationsændring. Gør følgende:
- Sæt miljøvariablen OBOT_SERVER_ENABLE_AUTHENTICATION til true på alle Obot-installationer, og genstart containeren, så login kræves for al adgang.
- Undersøg om port 8080 er eksponeret mod internettet eller mod netværk uden for jeres kontrol, og luk adgangen ned til kun betroede klienter, gerne via firewall eller VPN.
- Gennemgå Obots logfiler for administrative handlinger, oprettede brugere og nye MCP-servere fra perioden, hvor systemet har kørt uden autentificering.
- Vurder om /var/run/docker.sock er nødvendig at montere ind i containeren, og fjern adgangen hvis den ikke er kritisk for driften.
- Skift adgangskoder og adgangsnøgler, der har været tilgængelige for Obot, hvis I finder tegn på uautoriseret adgang.
- Kontakt en sikkerhedsrådgiver, hvis I finder spor af uautoriseret aktivitet, eller hvis I er usikre på, om jeres Docker-værter er blevet kompromitteret.
Slå autentificering til inden for 24 timer
Vi anbefaler, at I straks sætter OBOT_SERVER_ENABLE_AUTHENTICATION til true på alle Obot-installationer og bekræfter, at port 8080 ikke er åben mod utroede netværk. Det er en konfigurationsændring, der tager få minutter, og der er ingen god grund til at vente. Er Obot allerede afskærmet bag en firewall, kun tilgængelig for et lille antal betroede interne systemer, og har autentificering været slået til hele tiden, er risikoen begrænset og ændringen kan planlægges som en almindelig opgave frem for en akut opgave.
Tidslinje
Konkrete eksempler
Intern AI-automatisering hos en dansk produktionsvirksomhed
En it-afdeling har sat Obot op på en intern server til at automatisere rapportering og dataopslag ved hjælp af AI-agenter, og fulgt quickstart-vejledningen uden at ændre standardindstillingerne. Fordi serveren også er tilgængelig fra virksomhedens gæstenetværk, kan en person med adgang til det netværk nå port 8080 og få fuld administratoradgang til Obot uden login. Herfra kan personen starte en egen MCP-server, der udnytter adgangen til Docker-styringen på værten, og potentielt få kontrol over andre containere på samme server.
Ofte stillede spørgsmål
Er vi ramt af denne sårbarhed?
I er ramt, hvis I kører Obot via den dokumenterede Docker quickstart-kommando, og miljøvariablen OBOT_SERVER_ENABLE_AUTHENTICATION ikke er sat til true. Tjek jeres Docker-konfiguration og containerens miljøvariable for at bekræfte status.
Hvordan tjekker vi, om port 8080 er eksponeret?
Kør en port-scanning mod jeres server udefra, eller tjek firewall- og netværksregler for, om port 8080 er åben mod internettet eller mod netværk uden for jeres kontrol. Er porten kun tilgængelig internt for et fåtal betroede systemer, er eksponeringen mindre.
Kan vi vente til efter weekenden med at rette det?
Nej, ikke hvis porten er eksponeret mod utroede netværk. Fejlen kræver hverken login eller brugerhandling, og rettelsen er en enkel konfigurationsændring, som kan gennemføres med det samme uden nedetid af betydning.
Skal vi opdatere Obot til en ny version?
Nej, rettelsen er ikke en softwareopdatering men en ændring i dokumentationen og standardopsætningen. I skal selv sætte miljøvariablen OBOT_SERVER_ENABLE_AUTHENTICATION til true i jeres eksisterende installation.
Skal vi anmelde hændelsen, hvis vi finder tegn på misbrug?
Finder I tegn på, at nogen har opnået administratoradgang eller startet uautoriserede containere, bør I behandle det som en sikkerhedshændelse, sikre logs og vurdere om Datatilsynet eller CFCS skal underrettes, afhængigt af om persondata er berørt.
Påvirker det også andre AI-platforme, vi bruger?
Sårbarheden er specifik for Obot og dens quickstart-opsætning. Andre platforme bør vurderes selvstændigt for tilsvarende standardindstillinger uden autentificering.
CVSS-detaljer
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CWE-svaghedstyper
Original NVD-beskrivelse (engelsk)
Obot is an open-source AI agent/MCP platform. In all versions up to and including commit d7e6970, the Docker quickstart command documented in the README starts the container listening on 0.0.0.0:8080 with authentication disabled by default. When authentication is disabled, every request is mapped to a synthetic “nobody” user that holds the Owner and Admin roles, so any unauthenticated party who can reach the exposed port obtains full administrative access to the Obot API and UI, including the ability to register and launch attacker-controlled MCP servers. Because the quickstart also mounts /var/run/docker.sock into the container, the MCP runtime backend reachable this way has access to the host’s Docker control surface. The fix is documentation-only: the quickstart now enables authentication, and operators who followed the previous instructions should set OBOT_SERVER_ENABLE_AUTHENTICATION=true before exposing the host to any untrusted network.
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.