Over 135 000 OpenClaw-instanser er eksponert på internett. En kritisk sårbarhet muliggjør fjernkjøring av kode med ett klikk via hvilken som helst nettleser. Forskere har funnet over 1 100 ondsinnede ferdigheter som distribuerer Atomic Stealer på ClawHub. Microsoft publiserte et blogginnlegg med tittelen “Running OpenClaw Safely” som åpner med å bemerke at “for de fleste miljøer kan den riktige beslutningen være å ikke ta det i bruk.” Belgias nasjonale cybersikkerhetssenter utstedte et myndighetsvarsel. Cisco kalte personlige AI-agenter som OpenClaw for “et sikkerhetsmarerritt.”

Dette er ikke skremselspropaganda. Dette er fakta fra uavhengige sikkerhetsforskere, bedriftsleverandører og offentlige myndigheter. Hvis du kjører en OpenClaw-instans, angår dette deg.

Hva som gikk galt

OpenClaw ble designet for localhost. Du installerer det på maskinen din, snakker med det via et lokalt webgrensesnitt, og det utfører oppgaver på dine vegne. Sikkerhetsmodellen antok at personen som brukte grensesnittet var personen som satt ved tastaturet.

Så gikk OpenClaw fra 9 000 til over 200 000 GitHub-stjerner i løpet av noen uker. Folk distribuerte det på VPS-maskiner, eksponerte det mot internett og koblet det til meldingskanalene sine. Localhost-antakelsen brøt sammen i skala. (Vi dekket hele spekteret av distribusjonsalternativer og deres sikkerhetskompromisser i en separat guide.)

CVE-2026-25253: fjernkjøring av kode med ett klikk

Den mest alvorlige sårbarheten er CVE-2026-25253, vurdert til CVSS 8.8. OpenClaw validerte ikke WebSocket origin-headere. Slik fungerer angrepet:

  1. Offeret besøker en ondsinnet nettside (eller en side med en ondsinnet annonse).
  2. JavaScript på den siden åpner en WebSocket-tilkobling til localhost:18789, OpenClaws standardport.
  3. Siden nettleseren er på samme maskin, omgår tilkoblingen alle brannmurregler.
  4. Angriperen eksfiltrerer gateway-autentiseringstoken via WebSocket.
  5. Med tokenet har angriperen full kontroll: shell-tilgang, filllesing/-skriving og kommandokjøring.

Å binde til localhost hjelper ikke. Angrepet pivoterer gjennom offerets egen nettleser. SOCRadars analyse går gjennom hele kjeden.

Ondsinnede ferdigheter og forsyningskjedeangrep

Forskere fant 341 ondsinnede ferdigheter på ClawHub i begynnelsen av februar. Det tallet har siden vokst til over 1 100. ClawHavoc-kampanjen distribuerer Atomic Stealer gjennom ferdigheter som ser legitime ut, men som inneholder skjulte steg for kommandokjøring. Ferdigheter er Markdown-filer. En skjult instruksjon som sier “kjør denne shell-kommandoen” er enkel å bygge inn og vanskelig å oppdage.

Den 17. februar tok Cline forsyningskjedeangrepet ting videre. Et kompromittert npm-token ble brukt til å pushe en versjon av Cline CLI som stille installerte OpenClaw på utvikleres maskiner. Angrepet var rettet mot selve byggepipelinen.

Forskere har nå avslørt seks ytterligere sårbarheter i OpenClaws kjerne, inkludert CVE-2026-27001. OWASP Top 10 for agentapplikasjoner lister nå mange av disse mønstrene som topprisikoer. Som Conscias analyse uttrykker det, er dette en fullskala sikkerhetskrise.

Hvorfor et gateway-token ikke er nok

OpenClaws innebygde autentisering er et statisk token. Du setter det en gang, og hver forespørsel må inkludere det. Det er bedre enn ingenting. Men det har grunnleggende begrensninger.

Statiske tokens utløper ikke. Hvis et token lekker (gjennom CVE-2026-25253, gjennom logger, gjennom en ondsinnet ferdighet som leser miljøvariabler), har angriperen permanent tilgang til du oppdager det og roterer det manuelt.

Statiske tokens kan ikke begrenses. Gateway-tokenet gir full tilgang. Det finnes ingen måte å gi noen skrivebeskyttet tilgang eller begrense hva en autentisert sesjon kan gjøre.

Statiske tokens kan ikke knyttes til en bruker. Hvis tre personer deler et token, har du ingen revisjonsspor for hvem som gjorde hva.

De fleste VPS-distribusjonsguidene anbefaler å plassere OpenClaw bak nginx med grunnleggende autentisering. Det er bedre, men fortsatt en statisk legitimasjon. Hvis noen fanger den opp (nettverksavlytting på en ukryptert tilkobling, en kompromittert reverse proxy-konfigurasjon, en lekket .htpasswd-fil), er de inne.

Det grunnleggende problemet er dypere: autentisering skjer inne i applikasjonen. Hvis applikasjonen har en sårbarhet, kan autentiseringen omgås. CVE-2026-25253 demonstrerte dette nøyaktig. Gateway-tokenet eksisterte. Sårbarheten hentet det ut før applikasjonen i det hele tatt fikk sjansen til å verifisere det.

Det er derfor vi bygde OpenClaw.rocks med autentisering på proxy-nivå. Avsnittene nedenfor forklarer arkitekturen i detalj. Hvis du bare vil ha en sikker instans uten å bygge dette selv, se planene våre.

Hvordan vi sikrer gatewayen

Hos OpenClaw.rocks skjer autentisering på proxy-nivå, før forespørselen noensinne når OpenClaw-poden. Dette er en strukturell forskjell, ikke bare en konfigurasjonsforskjell.

Her er trelagsarkitekturen.

Lag 1: Signerte gateway-informasjonskapsler (HMAC-SHA256)

Når du får tilgang til din OpenClaw-instans gjennom OpenClaw.rocks-dashbordet, genererer serveren en signert informasjonskapsel. Formatet er:

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

Informasjonskapselen har en 4-timers TTL og oppdateres automatisk hvert 45. minutt. Den er avgrenset til stien /gw/{instanceId}, så en informasjonskapsel kan ikke brukes til å få tilgang til en annen instans. Den er HttpOnly (JavaScript kan ikke lese den), Secure (sendes bare over HTTPS) og SameSite=Lax (sendes ikke på forespørsler med kryssopprinnelse). HMAC verifiseres med tidssikrert sammenligning for å forhindre tidsangrep.

Selv om noen fanger opp informasjonskapselens verdi, kan de ikke forfalske en ny uten signeringshemligheten. Og informasjonskapselen inneholder i seg selv ingen legitimasjon som gir direkte tilgang til OpenClaw.

Lag 2: Traefik ForwardAuth

Hver forespørsel til en OpenClaw-instans passerer gjennom Traefik, vår reverse proxy. Før forespørselen videresendes, kaller Traefik et auth-gate-endepunkt som verifiserer den signerte informasjonskapselen.

Dette er ren HMAC-verifisering. Null databasekall. Null nettverksforespørsler til Supabase eller noen annen tjeneste. Beslutningen tas på mikrosekunder.

Hvis informasjonskapselen er ugyldig, utløpt eller mangler, avvises forespørselen på proxy-nivå. Forespørselen når aldri OpenClaw. Dette er den avgjørende forskjellen. I et typisk oppsett må OpenClaw selv avgjøre om en forespørsel skal tillates eller avvises. Hvis OpenClaw har en sårbarhet i autentiseringslogikken sin, kan en angriper snike seg gjennom. I vårt oppsett ser OpenClaw aldri uautentisert trafikk.

Lag 3: Gateway-tokeninjeksjon

Hver OpenClaw-instans har et innebygd gateway-token. Dette er det samme tokenet du ville konfigurert selv om du selvvertet. Forskjellen er hvordan det kommer til poden.

I et typisk selvvertingsoppsett limer du inn tokenet i en konfigurasjonsfil, kanskje lagrer det i en miljøvariabel, og håper det aldri lekker. Nettleseren din må sende det med hver forespørsel, som er nøyaktig hvordan CVE-2026-25253 hentet det ut.

I vårt oppsett genereres et kryptografisk tilfeldig 32-byte token ved instansopprettelse og lagres som en Kubernetes Secret. Traefik injiserer det som en Authorization-header på hver videresendt forespørsel. Nettleseren ser det aldri. Det dukker aldri opp i en konfigurasjonsfil du ved et uhell kan committe. Det reiser aldri over en WebSocket som en ondsinnet side kan kapre. Tokenet eksisterer, men det lever helt inne i klusteret, og beveger seg bare mellom Traefik og poden.

Hvorfor denne arkitekturen blokkerer CVE-2026-25253

CVE-2026-25253-angrepskjeden eksfiltrerer gateway-tokenet via WebSocket. La oss gå gjennom hva som skjer når det angrepet rettes mot en OpenClaw.rocks-instans:

  1. Angriperens JavaScript forsøker å åpne en WebSocket-tilkobling til OpenClaw-poden.
  2. Tilkoblingen treffer Traefik først. Traefik sjekker den signerte informasjonskapselen.
  3. Den ondsinnede siden er på en annen opprinnelse. SameSite=Lax-informasjonskapselen sendes ikke på WebSocket-tilkoblinger med kryssopprinnelse. Forespørselen avvises.
  4. Selv om informasjonskapselen på en eller annen måte ble vedlagt, kan angriperens side ikke lese den (HttpOnly). Det er ingenting å eksfiltrere.
  5. Selv om informasjonskapselen lekket, inneholder den ikke bearer-tokenet. Bearer-tokenet injiseres av Traefik og eksponeres aldri for nettleseren. Angriperen kan ikke rekonstruere det.

Det er ingenting å stjele fordi nettleseren aldri holder de virkelige legitimasjonene. Angrepsflaten som CVE-2026-25253 utnytter, eksisterer rett og slett ikke.

OpenClaw-sikkersjekkliste for selvvertere

Ikke alle ønsker administrert hosting, og det er helt greit. Hvis du kjører din egen OpenClaw-instans, her er en praktisk sjekkliste for 2026.

Er gateway-autentiseringstokenet ditt aktivert? Kjør openclaw doctor for å sjekke. Hvis gateway-autentisering er deaktivert, kontrollerer hvem som helst som kan nå port 18789 agenten din og alt den har tilgang til.

Er instansen din bak en reverse proxy med TLS? Vanlig HTTP betyr at hvem som helst på nettverksstien kan lese gateway-tokenet ditt under overføring. Bruk nginx, Caddy eller Traefik med et gyldig TLS-sertifikat. Let’s Encrypt er gratis.

Kjører du den nyeste versjonen? CVE-2026-25253 ble fikset i v2026.1.29. CVE-2026-27001 ble fikset i v2026.2.15. Hvis du kjører en eldre versjon, oppdater nå. Adversa AIs herdingsguide dekker ytterligere steg.

Har du gjennomgått dine installerte ferdigheter? ClawHavoc-kampanjen var spesifikt rettet mot ClawHub. Sjekk hver ferdighet du har installert. Hvis du ikke installerte den selv, fjern den og verifiser kilden.

Validerer reverse proxyen din WebSocket-opprinnelser? Dette er den spesifikke vektoren CVE-2026-25253 utnyttet. Reverse proxyen din bør avvise WebSocket-oppgraderingsforespørsler fra uventede opprinnelser. OpenClaws sikkerhetsdokumentasjon har konfigurasjonseksempler.

Skjer autentiseringen din før eller etter at forespørselen når OpenClaw? Dette er det viktigste spørsmålet. Hvis OpenClaw håndterer sin egen autentisering, kan en sårbarhet i OpenClaw omgå den. Hvis reverse proxyen din håndterer autentisering, når forespørselen aldri OpenClaw med mindre den allerede er verifisert.

Hva vi ikke løser

Ærlighet er viktig her. Autentisering på proxy-nivå løser gateway-sikkerhet. Det løser ikke alt.

Prompt-injeksjon er et problem på applikasjonsnivå. En listig utformet melding kan potensielt lure agenten til å utføre utilsiktede handlinger. Dette er et aktivt forskningsområde på tvers av hele AI-industrien, og ingen hostingleverandør kan fullstendig forhindre det i dag.

Ondsinnet ferdighetsadferd kjører inne i agentens kontekst. Hvis du installerer en ferdighet som eksfiltrerer data gjennom en tillatt HTTPS-utgang, kan proxy-autentisering ikke stoppe det. Det infrastrukturen vår gjør er å begrense eksplosjonsradiusen: hver instans kjører i sin egen Kubernetes-pod med nettverksisolasjon, droppede capabilities, seccomp og et skrivebeskyttet rotfilsystem. En kompromittert agent kan ikke nå andre agenter eller vertssystemet. Kubernetes-operatøren håndhever disse standardinnstillingene for hver instans.

LLM-leverandørtillit avhenger av planen din. Hvis du bruker dine egne API-nøkler (Light-planen), passerer samtalene dine gjennom den leverandøren du konfigurerer, og deres personvernpolicy gjelder. På Pro-planen ruter vi trafikk gjennom vår egen AI-gateway med forhåndskonfigurerte leverandører. Du trenger ikke overlevere API-nøklene dine til en OpenClaw-instans eller stole på at en tredjepartsnøkkel lagres sikkert. Gatewayen administrerer leverandørlegitimajson på dine vegne, og du ser eller håndterer dem aldri direkte.

Sikkerhet er lag. Vi håndterer infrastrukturlagene. Utfordringene på applikasjonsnivå er reelle og verdt å forstå.

Sikkerhet er en arkitekturbeslutning

OpenClaw-sikkerhetskrisen handler ikke om en CVE eller en batch med ondsinnede ferdigheter. Den handler om et verktøy designet for localhost som distribueres på internett av hundretusenvis av mennesker, med autentisering som skjer inne i applikasjonen det er ment å beskytte.

Å flytte autentisering til proxy-nivå er ikke en funksjon. Det er en arkitekturbeslutning. Det betyr at når neste OpenClaw CVE kommer (og det vil det), verifiseres autentiserte forespørsler fortsatt før de berører applikasjonen. Angrepsflaten er strukturelt mindre.

Vi tok den beslutningen fra dag en. Hver OpenClaw.rocks-instans kjører bak signerte informasjonskapsler, ForwardAuth-verifisering og instansspesifikke bearer-tokens. Ingen gateway-tokens i nettleseren. Ingen statiske legitimasjoner å eksfiltrere. Ingen autentiseringslogikk inne i den sårbare applikasjonen.

Hvis du vil lese mer om hvordan vi distribuerer OpenClaw på Kubernetes med full sikkerhetsherd, dekker distribusjonguiden det i detalj.

Hvis du bare vil ha en kjørende agent som forblir sikker uten å tenke på noe av dette, det er det vi bygde.

Kom i gang med OpenClaw.rocks eller utforsk Kubernetes-operatøren med åpen kildekode hvis du foretrekker å kjøre din egen infrastruktur.