Över 135 000 OpenClaw-instanser är exponerade på internet. En kritisk sårbarhet möjliggör fjärrkodexekvering med ett klick via vilken webbläsare som helst. Forskare har hittat över 1 100 skadliga skills som distribuerar Atomic Stealer på ClawHub. Microsoft publicerade ett blogginlägg med titeln “Running OpenClaw Safely” som inleds med att notera att “för de flesta miljöer kan det lämpliga beslutet vara att inte driftsätta det.” Belgiens nationella cybersäkerhetscenter utfärdade en myndighetsvarning. Cisco kallade personliga AI-agenter som OpenClaw för “en säkerhetsmardröm.”

Detta är inte skrämselpropaganda. Det är fakta från oberoende säkerhetsforskare, företagsleverantörer och myndigheter. Om du kör en OpenClaw-instans berör detta dig.

Vad som gick fel

OpenClaw designades för localhost. Du installerar det på din maskin, pratar med det via ett lokalt webbgränssnitt, och det utför saker åt dig. Säkerhetsmodellen antog att personen som använde gränssnittet var personen vid tangentbordet.

Sedan gick OpenClaw från 9 000 till över 200 000 GitHub-stjärnor på bara några veckor. Människor driftsatte det på VPS-maskiner, exponerade det mot internet och kopplade det till sina meddelandekanaler. Localhost-antagandet bröt samman i skala. (Vi gick igenom hela spektrumet av driftsättningsalternativ och deras säkerhetskompromisser i en separat guide.)

CVE-2026-25253: fjärrkodexekvering med ett klick

Den allvarligaste sårbarheten är CVE-2026-25253, med CVSS-poäng 8.8. OpenClaw validerade inte WebSocket-ursprungshuvuden. Så här fungerar attacken:

  1. Offret besöker en skadlig webbsida (eller en sida med en skadlig annons).
  2. JavaScript på den sidan öppnar en WebSocket-anslutning till localhost:18789, OpenClaw:s standardport.
  3. Eftersom webbläsaren är på samma maskin kringgår anslutningen alla brandväggsregler.
  4. Angriparen exfiltrerar gateway-autentiseringstoken via WebSocket.
  5. Med token har angriparen full kontroll: skalåtkomst, filläsning/skrivning och kommandoexekvering.

Att binda till localhost hjälper inte. Attacken pivoterar genom offrets egen webbläsare. SOCRadars analys går igenom hela kedjan.

Skadliga skills och leveranskedjeattacker

Forskare hittade 341 skadliga skills på ClawHub i början av februari. Det antalet har sedan dess vuxit till över 1 100. ClawHavoc-kampanjen distribuerar Atomic Stealer genom skills som ser legitima ut men innehåller dolda steg för kommandoexekvering. Skills är Markdown-filer. En dold instruktion som säger “kör detta skalkommando” är lätt att bädda in och svår att upptäcka.

Den 17 februari tog Cline-leveranskedjeattacken det ett steg längre. En komprometterad npm-token användes för att pusha en version av Cline CLI som tyst installerade OpenClaw på utvecklares maskiner. Attacken riktade sig mot själva byggpipelinen.

Forskare har nu avslöjat sex ytterligare sårbarheter i OpenClaw:s kärna, inklusive CVE-2026-27001. OWASP Top 10 för agentapplikationer listar nu många av dessa mönster som toppriskerna. Som Conscias analys uttrycker det, detta är en fullskalig säkerhetskris.

Varför en gateway-token inte räcker

OpenClaw:s inbyggda autentisering är en statisk token. Du ställer in den en gång, och varje förfrågan måste inkludera den. Det är bättre än ingenting. Men det har grundläggande begränsningar.

Statiska tokens förfaller inte. Om en token läcker (genom CVE-2026-25253, genom loggar, genom en skadlig skill som läser miljövariabler) har angriparen permanent åtkomst tills du upptäcker det och roterar den manuellt.

Statiska tokens kan inte begränsas. Gateway-token ger full åtkomst. Det finns inget sätt att ge någon skrivskyddad åtkomst eller begränsa vad en autentiserad session kan göra.

Statiska tokens kan inte kopplas till en användare. Om tre personer delar en token har du inget revisionsspår för vem som gjorde vad.

De flesta VPS-driftsättningsguider rekommenderar att placera OpenClaw bakom nginx med grundläggande autentisering. Det är bättre, men fortfarande en statisk behörighet. Om någon fångar den (nätverksavlyssning på en okrypterad anslutning, en komprometterad reverse proxy-konfiguration, en läckt .htpasswd-fil) är de inne.

Det grundläggande problemet är djupare: autentisering sker inuti applikationen. Om applikationen har en sårbarhet kan autentiseringen kringgås. CVE-2026-25253 demonstrerade detta exakt. Gateway-token existerade. Sårbarheten extraherade den innan applikationen ens fick chansen att verifiera den.

Det är därför vi byggde OpenClaw.rocks med autentisering på proxynivå. Avsnitten nedan förklarar arkitekturen i detalj. Om du bara vill ha en säker instans utan att bygga detta själv, se våra planer.

Hur vi säkrar gatewayen

På OpenClaw.rocks sker autentisering på proxynivå, innan förfrågan någonsin når OpenClaw-podden. Detta är en strukturell skillnad, inte bara en konfigurationsskillnad.

Här är den trelagers-arkitekturen.

Lager 1: Signerade gateway-cookies (HMAC-SHA256)

När du kommer åt din OpenClaw-instans genom OpenClaw.rocks-dashboarden genererar servern en signerad cookie. Formatet är:

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

Cookien har en 4-timmars TTL och uppdateras automatiskt var 45:e minut. Den är begränsad till sökvägen /gw/{instanceId}, så en cookie kan inte användas för att komma åt en annan instans. Den är HttpOnly (JavaScript kan inte läsa den), Secure (skickas bara över HTTPS) och SameSite=Lax (skickas inte vid cross-origin-förfrågningar). HMAC verifieras med tidssäker jämförelse för att förhindra tidbaserade attacker.

Även om någon fångar upp cookie-värdet kan de inte förfalska en ny utan signeringshemligheten. Och cookien i sig innehåller inga behörigheter som ger direkt åtkomst till OpenClaw.

Lager 2: Traefik ForwardAuth

Varje förfrågan till en OpenClaw-instans passerar genom Traefik, vår reverse proxy. Innan förfrågan vidarebefordras anropar Traefik en auth-gate-endpoint som verifierar den signerade cookien.

Detta är ren HMAC-verifiering. Noll databasanrop. Noll nätverksförfrågningar till Supabase eller någon annan tjänst. Beslutet fattas på mikrosekunder.

Om cookien är ogiltig, utgången eller saknas avvisas förfrågan på proxynivå. Förfrågan når aldrig OpenClaw. Detta är den avgörande skillnaden. I en typisk uppsättning måste OpenClaw självt avgöra om en förfrågan ska tillåtas eller avvisas. Om OpenClaw har en sårbarhet i sin autentiseringslogik kan en angripare smita igenom. I vår uppsättning ser OpenClaw aldrig oautentiserad trafik.

Lager 3: Gateway-tokeninjektion

Varje OpenClaw-instans har en inbyggd gateway-token. Det är samma token du skulle konfigurera själv om du självhostade. Skillnaden är hur den når podden.

I en typisk självhostinguppsättning klistrar du in token i en konfigurationsfil, kanske lagrar den i en miljövariabel, och hoppas att den aldrig läcker. Din webbläsare behöver skicka den med varje förfrågan, vilket är exakt hur CVE-2026-25253 exfiltrerade den.

I vår uppsättning genereras en kryptografiskt slumpmässig 32-bytes token vid instansskapande och lagras som en Kubernetes Secret. Traefik injicerar den som ett Authorization-huvud vid varje vidarebefordrad förfrågan. Webbläsaren ser den aldrig. Den dyker aldrig upp i en konfigurationsfil du kan råka commita. Den skickas aldrig över en WebSocket som en skadlig sida kan kapa. Token existerar, men den lever helt inuti klustret, och rör sig bara mellan Traefik och podden.

Varför denna arkitektur blockerar CVE-2026-25253

CVE-2026-25253-attackkedjan exfiltrerar gateway-token via WebSocket. Låt oss gå igenom vad som händer när den attacken riktas mot en OpenClaw.rocks-instans:

  1. Angriparens JavaScript försöker öppna en WebSocket-anslutning till OpenClaw-podden.
  2. Anslutningen träffar Traefik först. Traefik kontrollerar den signerade cookien.
  3. Den skadliga sidan är på ett annat ursprung. SameSite=Lax-cookien skickas inte vid cross-origin WebSocket-anslutningar. Förfrågan avvisas.
  4. Även om cookien på något sätt bifogades kan angriparens sida inte läsa den (HttpOnly). Det finns inget att exfiltrera.
  5. Även om cookien läckte innehåller den inte bearer-token. Bearer-token injiceras av Traefik och exponeras aldrig för webbläsaren. Angriparen kan inte rekonstruera den.

Det finns inget att stjäla eftersom webbläsaren aldrig håller de verkliga behörigheterna. Attackytan som CVE-2026-25253 utnyttjar existerar helt enkelt inte.

OpenClaw-säkerhetschecklista för självhosting

Inte alla vill ha hanterad hosting, och det är helt okej. Om du kör din egen OpenClaw-instans, här är en praktisk checklista för 2026.

Är din gateway-autentiseringstoken aktiverad? Kör openclaw doctor för att kontrollera. Om gateway-autentisering är inaktiverad kontrollerar vem som helst som kan nå port 18789 din agent och allt den har åtkomst till.

Är din instans bakom en reverse proxy med TLS? Ren HTTP innebär att vem som helst på nätverksvägen kan läsa din gateway-token under överföring. Använd nginx, Caddy eller Traefik med ett giltigt TLS-certifikat. Let’s Encrypt är gratis.

Kör du senaste versionen? CVE-2026-25253 åtgärdades i v2026.1.29. CVE-2026-27001 åtgärdades i v2026.2.15. Om du kör en äldre version, uppdatera nu. Adversa AI:s härdningsguide täcker ytterligare steg.

Har du granskat dina installerade skills? ClawHavoc-kampanjen riktade sig specifikt mot ClawHub. Kontrollera varje skill du har installerat. Om du inte installerade den själv, ta bort den och verifiera källan.

Validerar din reverse proxy WebSocket-ursprung? Detta är den specifika vektorn som CVE-2026-25253 utnyttjade. Din reverse proxy bör avvisa WebSocket-uppgraderingsförfrågningar från oväntade ursprung. OpenClaw:s säkerhetsdokumentation har konfigurationsexempel.

Sker din autentisering före eller efter att förfrågan når OpenClaw? Detta är den viktigaste frågan. Om OpenClaw hanterar sin egen autentisering kan en sårbarhet i OpenClaw kringgå den. Om din reverse proxy hanterar autentisering når förfrågan aldrig OpenClaw om den inte redan är verifierad.

Vad vi inte löser

Ärlighet är viktigt här. Autentisering på proxynivå löser gateway-säkerhet. Det löser inte allt.

Promptinjektion är ett problem på applikationsnivå. Ett skickligt utformat meddelande kan potentiellt lura agenten att utföra oavsiktliga handlingar. Detta är ett aktivt forskningsområde inom hela AI-industrin, och ingen hostingleverantör kan fullt ut förhindra det idag.

Skadligt skillbeteende körs inuti agentens kontext. Om du installerar en skill som exfiltrerar data genom en tillåten HTTPS-utgång kan proxyautentisering inte stoppa det. Vad vår infrastruktur gör är att begränsa explosionsradien: varje instans körs i sin egen Kubernetes-podd med nätverksisolering, borttagna capabilities, seccomp och ett skrivskyddat rotfilsystem. En komprometterad agent kan inte nå andra agenter eller värdssystemet. Kubernetes-operatorn tillämpar dessa standardinställningar för varje instans.

LLM-leverantörsförtroende beror på din plan. Om du använder dina egna API-nycklar (Light-planen) passerar dina konversationer genom vilken leverantör du konfigurerar, och deras integritetspolicy gäller. På Pro-planen dirigerar vi trafik genom vår egen AI-gateway med förkonfigurerade leverantörer. Du behöver inte lämna dina API-nycklar till en OpenClaw-instans eller lita på att en tredjepartsnyckel lagras säkert. Gatewayen hanterar leverantörers behörigheter åt dig, och du ser eller hanterar dem aldrig direkt.

Säkerhet är lager. Vi hanterar infrastrukturlagren. Utmaningarna på applikationsnivå är verkliga och värda att förstå.

Säkerhet är ett arkitekturbeslut

OpenClaw-säkerhetskrisen handlar inte om en CVE eller en batch skadliga skills. Det handlar om ett verktyg designat för localhost som driftsätts på internet av hundratusentals människor, med autentisering som sker inuti applikationen den är tänkt att skydda.

Att flytta autentisering till proxynivå är inte en funktion. Det är ett arkitekturbeslut. Det innebär att när nästa OpenClaw CVE släpps (och det kommer det att göra) verifieras autentiserade förfrågningar fortfarande innan de berör applikationen. Attackytan är strukturellt mindre.

Vi fattade det beslutet dag ett. Varje OpenClaw.rocks-instans körs bakom signerade cookies, ForwardAuth-verifiering och instansspecifika bearer-tokens. Inga gateway-tokens i webbläsaren. Inga statiska behörigheter att exfiltrera. Ingen autentiseringslogik inuti den sårbara applikationen.

Om du vill läsa mer om hur vi driftsätter OpenClaw på Kubernetes med full säkerhetshärdning täcker driftsättningsguiden det i detalj.

Om du bara vill ha en körande agent som förblir säker utan att tänka på något av detta, det är vad vi byggde.

Kom igång med OpenClaw.rocks eller utforska Kubernetes-operatorn med öppen källkod om du föredrar att köra din egen infrastruktur.