Over 135.000 OpenClaw-instanser er eksponeret på internettet. En kritisk sårbarhed muliggør fjernkodeeksekvering med ét klik via enhver browser. Forskere har fundet over 1.100 ondsindede skills, der distribuerer Atomic Stealer på ClawHub. Microsoft offentliggjorde et blogindlæg med titlen “Running OpenClaw Safely”, der indledes med at bemærke, at “for de fleste miljøer kan den passende beslutning være ikke at implementere det.” Belgiens nationale cybersikkerhedscenter udstedte en myndigheds-advarsel. Cisco kaldte personlige AI-agenter som OpenClaw for “et sikkerhedsmareridt.”

Dette er ikke skræmmekampagne. Det er fakta fra uafhængige sikkerhedsforskere, virksomhedsleverandører og offentlige myndigheder. Hvis du kører en OpenClaw-instans, vedrører dette dig.

Hvad der gik galt

OpenClaw blev designet til localhost. Du installerer det på din maskine, taler med det via en lokal webgrænseflade, og det udfører opgaver på dine vegne. Sikkerhedsmodellen antog, at personen der tilgik grænsefladen, var personen ved tastaturet.

Derefter gik OpenClaw fra 9.000 til over 200.000 GitHub-stjerner på blot nogle uger. Folk implementerede det på VPS-maskiner, eksponerede det mod internettet og tilsluttede det til deres beskedkanaler. Localhost-antagelsen brød sammen i skala. (Vi dækkede det fulde spektrum af implementeringsmuligheder og deres sikkerhedskompromiser i en separat guide.)

CVE-2026-25253: fjernkodeeksekvering med ét klik

Den mest alvorlige sårbarhed er CVE-2026-25253, vurderet til CVSS 8.8. OpenClaw validerede ikke WebSocket-origin-headers. Sådan fungerer angrebet:

  1. Offeret besøger en ondsindet webside (eller en side med en ondsindet annonce).
  2. JavaScript på den side åbner en WebSocket-forbindelse til localhost:18789, OpenClaw:s standardport.
  3. Da browseren er på samme maskine, omgår forbindelsen alle firewallregler.
  4. Angriberen exfiltrerer gateway-autentificerings-token via WebSocket.
  5. Med token har angriberen fuld kontrol: shell-adgang, fillæsning/-skrivning og kommandoeksekvering.

At binde til localhost hjælper ikke. Angrebet pivoterer gennem offerets egen browser. SOCRadars analyse gennemgår hele kæden.

Ondsindede skills og forsyningskædeangreb

Forskere fandt 341 ondsindede skills på ClawHub i begyndelsen af februar. Det tal er siden vokset til over 1.100. ClawHavoc-kampagnen distribuerer Atomic Stealer gennem skills, der ser legitime ud, men indeholder skjulte trin til kommandoeksekvering. Skills er Markdown-filer. En skjult instruktion der siger “kør denne shell-kommando” er let at indlejre og svær at opdage.

Den 17. februar tog Cline-forsyningskædeangrebet tingene videre. Et kompromitteret npm-token blev brugt til at pushe en version af Cline CLI, der stille installerede OpenClaw på udvikleres maskiner. Angrebet var rettet mod selve byggepipelinen.

Forskere har nu afsløret seks yderligere sårbarheder i OpenClaw:s kerne, herunder CVE-2026-27001. OWASP Top 10 for agentapplikationer lister nu mange af disse mønstre som toprisici. Som Conscias analyse udtrykker det, er dette en fuldskala sikkerhedskrise.

Hvorfor en gateway-token ikke er nok

OpenClaw:s indbyggede autentificering er en statisk token. Du indstiller den én gang, og hver forespørgsel skal inkludere den. Det er bedre end ingenting. Men den har grundlæggende begrænsninger.

Statiske tokens udløber ikke. Hvis en token lækker (gennem CVE-2026-25253, gennem logs, gennem en ondsindet skill der læser miljøvariabler), har angriberen permanent adgang, indtil du opdager det og roterer den manuelt.

Statiske tokens kan ikke begrænses. Gateway-token giver fuld adgang. Der er ingen måde at give nogen skrivebeskyttet adgang eller begrænse, hvad en autentificeret session kan gøre.

Statiske tokens kan ikke knyttes til en bruger. Hvis tre personer deler en token, har du ingen revisionsspor for, hvem der gjorde hvad.

De fleste VPS-implementeringsguider anbefaler at placere OpenClaw bag nginx med grundlæggende autentificering. Det er bedre, men stadig en statisk legitimation. Hvis nogen opfanger den (netværksaflytning på en ukrypteret forbindelse, en kompromitteret reverse proxy-konfiguration, en lækket .htpasswd-fil), er de inde.

Det grundlæggende problem er dybere: autentificering foregår inde i applikationen. Hvis applikationen har en sårbarhed, kan autentificeringen omgås. CVE-2026-25253 demonstrerede dette præcist. Gateway-token eksisterede. Sårbarheden udtrak den, før applikationen overhovedet fik chancen for at verificere den.

Det er derfor, vi byggede OpenClaw.rocks med autentificering på proxyniveau. Afsnittene nedenfor forklarer arkitekturen i detaljer. Hvis du bare vil have en sikker instans uden at bygge dette selv, se vores planer.

Hvordan vi sikrer gatewayen

Hos OpenClaw.rocks foregår autentificering på proxyniveauet, før forespørgslen overhovedet når OpenClaw-podden. Dette er en strukturel forskel, ikke bare en konfigurationsforskel.

Her er den tre-lags arkitektur.

Lag 1: Signerede gateway-cookies (HMAC-SHA256)

Når du tilgår din OpenClaw-instans gennem OpenClaw.rocks-dashboardet, genererer serveren en signeret cookie. Formatet er:

{expiry}.{userId}.{instanceId}.{hmac_base64url}

Cookien har en 4-timers TTL og opdateres automatisk hvert 45. minut. Den er begrænset til stien /gw/{instanceId}, så én cookie kan ikke bruges til at tilgå en anden instans. Den er HttpOnly (JavaScript kan ikke læse den), Secure (sendes kun over HTTPS) og SameSite=Lax (sendes ikke ved cross-origin-forespørgsler). HMAC verificeres med tidssikker sammenligning for at forhindre tidsangreb.

Selv hvis nogen opfanger cookieværdien, kan de ikke forfalske en ny uden signeringshemmeligheden. Og cookien indeholder i sig selv ingen legitimationsoplysninger, der giver direkte adgang til OpenClaw.

Lag 2: Traefik ForwardAuth

Hver forespørgsel til en OpenClaw-instans passerer gennem Traefik, vores reverse proxy. Før forespørgslen videresendes, kalder Traefik et auth-gate-endpoint, der verificerer den signerede cookie.

Dette er ren HMAC-verificering. Nul databasekald. Nul netværksforespørgsler til Supabase eller nogen anden tjeneste. Beslutningen tages på mikrosekunder.

Hvis cookien er ugyldig, udløbet eller mangler, afvises forespørgslen på proxyniveau. Forespørgslen når aldrig OpenClaw. Dette er den afgørende forskel. I en typisk opsætning skal OpenClaw selv afgøre, om en forespørgsel skal tillades eller afvises. Hvis OpenClaw har en sårbarhed i sin autentificeringslogik, kan en angriber slippe igennem. I vores opsætning ser OpenClaw aldrig uautentificeret trafik.

Lag 3: Gateway-tokeninjektion

Hver OpenClaw-instans har en indbygget gateway-token. Det er den samme token, du ville konfigurere selv, hvis du selvhostede. Forskellen er, hvordan den når podden.

I en typisk selvhosting-opsætning indsætter du token i en konfigurationsfil, gemmer den måske i en miljøvariabel og håber, at den aldrig lækker. Din browser skal sende den med hver forespørgsel, hvilket er præcis, hvordan CVE-2026-25253 exfiltrerede den.

I vores opsætning genereres en kryptografisk tilfældig 32-bytes token ved instansoprettelse og gemmes som en Kubernetes Secret. Traefik injicerer den som en Authorization-header ved hver videresendt forespørgsel. Browseren ser den aldrig. Den dukker aldrig op i en konfigurationsfil, du ved et uheld kan committe. Den rejser aldrig over en WebSocket, som en ondsindet side kan kapre. Token eksisterer, men den lever udelukkende inde i klustret og bevæger sig kun mellem Traefik og podden.

Hvorfor denne arkitektur blokerer CVE-2026-25253

CVE-2026-25253-angrebskæden exfiltrerer gateway-token via WebSocket. Lad os gennemgå, hvad der sker, når det angreb rettes mod en OpenClaw.rocks-instans:

  1. Angriberens JavaScript forsøger at åbne en WebSocket-forbindelse til OpenClaw-podden.
  2. Forbindelsen rammer Traefik først. Traefik kontrollerer den signerede cookie.
  3. Den ondsindede side er på et andet origin. SameSite=Lax-cookien sendes ikke ved cross-origin WebSocket-forbindelser. Forespørgslen afvises.
  4. Selv hvis cookien på en eller anden måde blev vedhæftet, kan angriberens side ikke læse den (HttpOnly). Der er intet at exfiltrere.
  5. Selv hvis cookien lækkede, indeholder den ikke bearer-token. Bearer-token injiceres af Traefik og eksponeres aldrig for browseren. Angriberen kan ikke rekonstruere den.

Der er intet at stjæle, fordi browseren aldrig holder de rigtige legitimationsoplysninger. Angrebsfladen som CVE-2026-25253 udnytter, eksisterer simpelthen ikke.

OpenClaw-sikkerhedstjekliste for selvhostere

Ikke alle ønsker administreret hosting, og det er fint. Hvis du kører din egen OpenClaw-instans, er her en praktisk tjekliste for 2026.

Er din gateway-autentificeringstoken aktiveret? Kør openclaw doctor for at tjekke. Hvis gateway-autentificering er deaktiveret, kontrollerer enhver, der kan nå port 18789, din agent og alt, den har adgang til.

Er din instans bag en reverse proxy med TLS? Ren HTTP betyder, at enhver på netværksstien kan læse din gateway-token under overførsel. Brug nginx, Caddy eller Traefik med et gyldigt TLS-certifikat. Let’s Encrypt er gratis.

Kører du den seneste version? CVE-2026-25253 blev rettet i v2026.1.29. CVE-2026-27001 blev rettet i v2026.2.15. Hvis du kører en ældre version, opdatér nu. Adversa AI’s hærdningsguide dækker yderligere trin.

Har du gennemgået dine installerede skills? ClawHavoc-kampagnen var specifikt rettet mod ClawHub. Tjek hver skill, du har installeret. Hvis du ikke installerede den selv, fjern den og verificér kilden.

Validerer din reverse proxy WebSocket-origins? Dette er den specifikke vektor, CVE-2026-25253 udnyttede. Din reverse proxy bør afvise WebSocket-opgraderingsforespørgsler fra uventede origins. OpenClaw:s sikkerhedsdokumentation har konfigurationseksempler.

Foregår din autentificering før eller efter, at forespørgslen når OpenClaw? Dette er det vigtigste spørgsmål. Hvis OpenClaw håndterer sin egen autentificering, kan en sårbarhed i OpenClaw omgå den. Hvis din reverse proxy håndterer autentificering, når forespørgslen aldrig OpenClaw, medmindre den allerede er verificeret.

Hvad vi ikke løser

Ærlighed er vigtig her. Proxy-niveau-autentificering løser gateway-sikkerhed. Det løser ikke alt.

Prompt-injektion er et applikationsniveau-problem. En snedigt udformet besked kan potentielt narre agenten til at udføre utilsigtede handlinger. Dette er et aktivt forskningsområde på tværs af hele AI-industrien, og ingen hostingudbyder kan fuldt ud forhindre det i dag.

Ondsindet skill-adfærd kører inden for agentens kontekst. Hvis du installerer en skill, der exfiltrerer data gennem en tilladt HTTPS-udgang, kan proxy-autentificering ikke stoppe det. Hvad vores infrastruktur gør, er at begrænse eksplosionsradius: hver instans kører i sin egen Kubernetes-pod med netværksisolering, droppede capabilities, seccomp og et skrivebeskyttet rodfilsystem. En kompromitteret agent kan ikke nå andre agenter eller værtssystemet. Kubernetes-operatoren håndhæver disse standardindstillinger for hver instans.

LLM-leverandørtillid afhænger af din plan. Hvis du bruger dine egne API-nøgler (Light-planen), passerer dine samtaler gennem den leverandør, du konfigurerer, og deres privatlivspolitik gælder. På Pro-planen dirigerer vi trafik gennem vores egen AI-gateway med forudkonfigurerede leverandører. Du behøver ikke overlevere dine API-nøgler til en OpenClaw-instans eller stole på, at en tredjepartsnøgle opbevares sikkert. Gatewayen administrerer leverandørlegitimationsoplysninger på dine vegne, og du ser eller håndterer dem aldrig direkte.

Sikkerhed er lag. Vi håndterer infrastrukturlagene. Udfordringerne på applikationsniveau er reelle og værd at forstå.

Sikkerhed er en arkitekturbeslutning

OpenClaw-sikkerhedskrisen handler ikke om én CVE eller én batch af ondsindede skills. Den handler om et værktøj designet til localhost, der implementeres på internettet af hundredtusindvis af mennesker, med autentificering der foregår inde i den applikation, det skal beskytte.

At flytte autentificering til proxyniveauet er ikke en funktion. Det er en arkitekturbeslutning. Det betyder, at når den næste OpenClaw CVE dropper (og det vil den), verificeres autentificerede forespørgsler stadig, før de berører applikationen. Angrebsfladen er strukturelt mindre.

Vi tog den beslutning fra dag ét. Hver OpenClaw.rocks-instans kører bag signerede cookies, ForwardAuth-verificering og instansspecifikke bearer-tokens. Ingen gateway-tokens i browseren. Ingen statiske legitimationsoplysninger at exfiltrere. Ingen autentificeringslogik inde i den sårbare applikation.

Hvis du vil læse mere om, hvordan vi implementerer OpenClaw på Kubernetes med fuld sikkerhedshærdning, dækker implementeringsguiden det i detaljer.

Hvis du bare vil have en kørende agent, der forbliver sikker uden at tænke over noget af dette, det er det, vi har bygget.

Kom i gang med OpenClaw.rocks eller udforsk Kubernetes-operatoren med open source, hvis du foretrækker at køre din egen infrastruktur.