Meer dan 135.000 OpenClaw-instanties zijn blootgesteld op het internet. Een kritieke kwetsbaarheid maakt remote code execution mogelijk met één klik vanuit elke browser. Onderzoekers hebben meer dan 1.100 kwaadaardige skills gevonden die Atomic Stealer verspreiden via ClawHub. Microsoft publiceerde een blogpost getiteld “Running OpenClaw Safely” die begint met de opmerking dat “voor de meeste omgevingen de juiste beslissing zou kunnen zijn om het niet te deployen.” Het Belgische nationale cyberbeveiligingscentrum gaf een overheidswaarschuwing uit. Cisco noemde persoonlijke AI-agenten zoals OpenClaw “een beveiligingsnachtmerrie.”

Dit is geen angstverhaal. Dit zijn feiten van onafhankelijke beveiligingsonderzoekers, enterprise-leveranciers en overheidsinstanties. Als u een OpenClaw-instantie draait, gaat dit u aan.

Wat er is misgegaan

OpenClaw was ontworpen voor localhost. U installeert het op uw machine, communiceert via een lokale webinterface en het voert taken uit namens u. Het beveiligingsmodel ging ervan uit dat de persoon die de interface benaderde, de persoon was die achter het toetsenbord zat.

Toen ging OpenClaw van 9.000 naar meer dan 200.000 GitHub-sterren in een kwestie van weken. Mensen deployen het op VPS-servers, stelden het bloot aan het internet en verbonden het met hun berichtenkanalen. De localhost-aanname bezweek op schaal. (We behandelden het volledige spectrum van deploymentopties en hun beveiligingsafwegingen in een aparte gids.)

CVE-2026-25253: remote code execution met één klik

De ernstigste kwetsbaarheid is CVE-2026-25253, met CVSS-score 8.8. OpenClaw valideerde geen WebSocket-origin-headers. Zo werkt de aanval:

  1. Het slachtoffer bezoekt een kwaadaardige webpagina (of een pagina met een kwaadaardige advertentie).
  2. JavaScript op die pagina opent een WebSocket-verbinding naar localhost:18789, de standaard OpenClaw-poort.
  3. Omdat de browser op dezelfde machine staat, omzeilt de verbinding alle firewallregels.
  4. De aanvaller exfiltreert het gateway-authenticatietoken via de WebSocket.
  5. Met het token heeft de aanvaller volledige controle: shell-toegang, bestanden lezen/schrijven en opdrachten uitvoeren.

Binden aan localhost helpt niet. De aanval maakt gebruik van de eigen browser van het slachtoffer als draaipunt. De analyse van SOCRadar doorloopt de volledige keten.

Kwaadaardige skills en supply chain-aanvallen

Onderzoekers vonden 341 kwaadaardige skills op ClawHub begin februari. Dat aantal is sindsdien gegroeid tot meer dan 1.100. De ClawHavoc-campagne verspreidt Atomic Stealer via skills die er legitiem uitzien maar verborgen stappen voor opdrachtuitvoering bevatten. Skills zijn Markdown-bestanden. Een verborgen instructie die zegt “voer dit shellcommando uit” is eenvoudig in te sluiten en moeilijk te herkennen.

Op 17 februari ging de Cline supply chain-aanval nog een stap verder. Een gecompromitteerd npm-token werd gebruikt om een versie van de Cline CLI te publiceren die stilletjes OpenClaw installeerde op machines van ontwikkelaars. De aanval richtte zich op de build-pipeline zelf.

Onderzoekers hebben inmiddels zes aanvullende kwetsbaarheden in de kern van OpenClaw onthuld, waaronder CVE-2026-27001. De OWASP Top 10 voor Agentische Applicaties vermeldt veel van deze patronen nu als toprisico’s. Zoals de analyse van Conscia het formuleert: dit is een volwaardige beveiligingscrisis.

Waarom een gateway-token niet genoeg is

De ingebouwde authenticatie van OpenClaw is een statisch token. U stelt het eenmaal in, en elk verzoek moet het bevatten. Het is beter dan niets. Maar het heeft fundamentele beperkingen.

Statische tokens verlopen niet. Als een token uitlekt (via CVE-2026-25253, via logs, via een kwaadaardige skill die omgevingsvariabelen leest), heeft de aanvaller permanente toegang totdat u het opmerkt en handmatig roteert.

Statische tokens kunnen niet in scope worden beperkt. Het gateway-token verleent volledige toegang. Er is geen manier om iemand alleen-lezen toegang te geven of te beperken wat een geauthenticeerde sessie kan doen.

Statische tokens kunnen niet aan een gebruiker worden gekoppeld. Als drie mensen een token delen, is er geen audittrail over wie wat heeft gedaan.

De meeste VPS-deploymentgidsen adviseren om OpenClaw achter nginx met basic auth te plaatsen. Dat is beter, maar het blijft een statische credential. Als iemand het onderschept (netwerk-sniffing op een onversleutelde verbinding, een gecompromitteerde reverse proxy-configuratie, een gelekt .htpasswd-bestand), heeft die persoon toegang.

Het fundamentele probleem ligt dieper: authenticatie vindt plaats binnen de applicatie. Als de applicatie een kwetsbaarheid heeft, kan authenticatie worden omzeild. CVE-2026-25253 demonstreerde dit precies. Het gateway-token bestond. De kwetsbaarheid extraheerde het voordat de applicatie zelfs de kans kreeg om het te verifiëren.

Daarom hebben we OpenClaw.rocks gebouwd met authenticatie op proxyniveau. De volgende secties leggen de architectuur in detail uit. Als u gewoon een veilige instantie wilt zonder dit alles zelf te bouwen, bekijk onze plannen.

Hoe wij de gateway beveiligen

Bij OpenClaw.rocks vindt authenticatie plaats op de proxylaag, voordat het verzoek de OpenClaw-pod bereikt. Dit is een structureel verschil, niet slechts een configuratieverschil.

Hier is de drielaagse architectuur.

Laag 1: Ondertekende gateway-cookies (HMAC-SHA256)

Wanneer u uw OpenClaw-instantie benadert via het OpenClaw.rocks-dashboard, genereert de server een ondertekende cookie. Het formaat is:

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

De cookie heeft een TTL van 4 uur en wordt elke 45 minuten automatisch vernieuwd. Hij is pad-gebonden aan /gw/{instanceId}, zodat één cookie niet kan worden gebruikt om een andere instantie te benaderen. Hij is HttpOnly (JavaScript kan hem niet lezen), Secure (wordt alleen via HTTPS verzonden) en SameSite=Lax (wordt niet verzonden bij cross-origin verzoeken). De HMAC wordt geverifieerd met een timing-safe vergelijking om timing-aanvallen te voorkomen.

Zelfs als iemand de cookiewaarde onderschept, kan diegene geen nieuwe vervalsen zonder het ondertekeningsgeheim. En de cookie zelf bevat geen credentials die directe toegang tot OpenClaw verlenen.

Laag 2: Traefik ForwardAuth

Elk verzoek aan een OpenClaw-instantie passeert Traefik, onze reverse proxy. Voordat het verzoek wordt doorgestuurd, roept Traefik een auth-gate endpoint aan dat de ondertekende cookie verifieert.

Dit is pure HMAC-verificatie. Nul databaseaanroepen. Nul netwerkverzoeken naar Supabase of een andere dienst. De beslissing wordt genomen in microseconden.

Als de cookie ongeldig, verlopen of afwezig is, wordt het verzoek afgewezen op de proxylaag. Het verzoek bereikt OpenClaw nooit. Dit is het cruciale verschil. In een typische setup moet OpenClaw zelf beslissen of een verzoek wordt toegestaan of afgewezen. Als OpenClaw een kwetsbaarheid in zijn authenticatielogica heeft, kan een aanvaller erdoorheen glippen. In onze setup ziet OpenClaw nooit ongeauthenticeerd verkeer.

Laag 3: Gateway-token injectie

Elke OpenClaw-instantie heeft een ingebouwd gateway-token. Dit is hetzelfde token dat u zelf zou configureren als u zelf zou hosten. Het verschil zit in hoe het de pod bereikt.

In een typische self-hosting setup plakt u het token in een configuratiebestand, slaat u het misschien op in een omgevingsvariabele, en hoopt u dat het nooit uitlekt. Uw browser moet het bij elk verzoek meesturen, wat precies de manier is waarop CVE-2026-25253 het exfiltreerde.

In onze setup wordt een cryptografisch willekeurig 32-byte token gegenereerd bij het aanmaken van de instantie en opgeslagen als een Kubernetes Secret. Traefik injecteert het als een Authorization-header bij elk doorgestuurd verzoek. De browser ziet het nooit. Het verschijnt nooit in een configuratiebestand dat u per ongeluk zou kunnen committen. Het reist nooit over een WebSocket die een kwaadaardige pagina zou kunnen kapen. Het token bestaat, maar het leeft volledig binnen het cluster en beweegt zich alleen tussen Traefik en de pod.

Waarom deze architectuur CVE-2026-25253 blokkeert

De aanvalsketen van CVE-2026-25253 exfiltreert het gateway-token via WebSocket. Laten we doorlopen wat er gebeurt wanneer die aanval gericht is op een OpenClaw.rocks-instantie:

  1. Het JavaScript van de aanvaller probeert een WebSocket te openen naar de OpenClaw-pod.
  2. De verbinding bereikt eerst Traefik. Traefik controleert de ondertekende cookie.
  3. De kwaadaardige pagina staat op een andere origin. De SameSite=Lax cookie wordt niet verstuurd bij cross-origin WebSocket-verbindingen. Het verzoek wordt afgewezen.
  4. Zelfs als de cookie op de een of andere manier zou worden bijgevoegd, kan de pagina van de aanvaller hem niet lezen (HttpOnly). Er is niets om te exfiltreren.
  5. Zelfs als de cookie zou uitlekken, bevat hij niet het bearer-token. Het bearer-token wordt geïnjecteerd door Traefik, nooit blootgesteld aan de browser. De aanvaller kan het niet reconstrueren.

Er is niets te stelen omdat de browser nooit de echte credentials bezit. Het aanvalsoppervlak dat CVE-2026-25253 exploiteert, bestaat simpelweg niet.

OpenClaw-beveiligingschecklist voor self-hosters

Niet iedereen wil managed hosting, en dat is prima. Als u uw eigen OpenClaw-instantie draait, hier een praktische checklist voor 2026.

Is uw gateway-authenticatietoken ingeschakeld? Voer openclaw doctor uit om dit te controleren. Als gateway-auth is uitgeschakeld, beheert iedereen die poort 18789 kan bereiken uw agent en alles waartoe deze toegang heeft.

Staat uw instantie achter een reverse proxy met TLS? Onversleuteld HTTP betekent dat iedereen op het netwerkpad uw gateway-token in transit kan lezen. Gebruik nginx, Caddy of Traefik met een geldig TLS-certificaat. Let’s Encrypt is gratis.

Draait u de nieuwste versie? CVE-2026-25253 werd gepatcht in v2026.1.29. CVE-2026-27001 werd gepatcht in v2026.2.15. Als u een oudere versie draait, update dan nu. De Adversa AI hardening-gids behandelt aanvullende stappen.

Hebt u uw geïnstalleerde skills gecontroleerd? De ClawHavoc-campagne richtte zich specifiek op ClawHub. Controleer elke skill die u hebt geïnstalleerd. Als u hem niet zelf hebt geïnstalleerd, verwijder hem dan en verifieer de bron.

Valideert uw reverse proxy WebSocket-origins? Dit is de specifieke vector die CVE-2026-25253 exploiteerde. Uw reverse proxy zou WebSocket-upgrade-verzoeken van onverwachte origins moeten afwijzen. De beveiligingsdocumentatie van OpenClaw bevat configuratievoorbeelden.

Vindt uw authenticatie plaats voor of na het bereiken van OpenClaw? Dit is de vraag die er het meest toe doet. Als OpenClaw zijn eigen authenticatie afhandelt, kan een kwetsbaarheid in OpenClaw deze omzeilen. Als uw reverse proxy de authenticatie afhandelt, bereikt het verzoek OpenClaw pas als het al is geverifieerd.

Wat wij niet oplossen

Eerlijkheid is hier belangrijk. Authenticatie op proxyniveau lost gateway-beveiliging op. Het lost niet alles op.

Prompt injection is een probleem op applicatieniveau. Een slim opgesteld bericht kan de agent mogelijk verleiden tot onbedoelde acties. Dit is een actief onderzoeksgebied in de hele AI-industrie, en geen enkele hostingprovider kan het vandaag volledig voorkomen.

Kwaadaardig skill-gedrag draait binnen de context van de agent. Als u een skill installeert die gegevens exfiltreert via toegestaan HTTPS-uitgaand verkeer, kan proxy-auth dat niet stoppen. Wat onze infrastructuur wel doet, is de schaderadius beperken: elke instantie draait in zijn eigen Kubernetes-pod met netwerkisolatie, verwijderde capabilities, seccomp en een alleen-lezen root-bestandssysteem. Een gecompromitteerde agent kan geen andere agenten of het hostsysteem bereiken. De Kubernetes-operator handhaaft deze standaardinstellingen voor elke instantie.

Vertrouwen in de LLM-provider hangt af van uw plan. Als u uw eigen API-sleutels gebruikt (Light-plan), lopen uw gesprekken via de provider die u configureert, en geldt diens privacybeleid. Bij het Pro-plan routeren wij het verkeer via onze eigen AI-gateway met vooraf geconfigureerde providers. U hoeft uw API-sleutels niet aan een OpenClaw-instantie te geven of erop te vertrouwen dat een sleutel van derden veilig wordt opgeslagen. De gateway beheert de provider-credentials namens u, en u ziet of behandelt ze nooit rechtstreeks.

Beveiliging bestaat uit lagen. Wij verzorgen de infrastructuurlagen. De uitdagingen op applicatieniveau zijn reëel en het waard om te begrijpen.

Beveiliging is een architectuurbeslissing

De OpenClaw-beveiligingscrisis gaat niet over één CVE of één partij kwaadaardige skills. Het gaat over een tool ontworpen voor localhost die op het internet wordt gedeployed door honderdduizenden mensen, met authenticatie die plaatsvindt binnen de applicatie die het geacht wordt te beschermen.

Authenticatie verplaatsen naar de proxylaag is geen feature. Het is een architectuurbeslissing. Het betekent dat wanneer de volgende OpenClaw-CVE verschijnt (en dat zal gebeuren), geauthenticeerde verzoeken nog steeds worden geverifieerd voordat ze de applicatie bereiken. Het aanvalsoppervlak is structureel kleiner.

We hebben die beslissing op dag één genomen. Elke OpenClaw.rocks-instantie draait achter ondertekende cookies, ForwardAuth-verificatie en per-instantie bearer-tokens. Geen gateway-tokens in de browser. Geen statische credentials om te exfiltreren. Geen authenticatielogica binnen de kwetsbare applicatie.

Als u meer wilt lezen over hoe wij OpenClaw op Kubernetes deployen met volledige beveiligingshardening, behandelt de deploymentgids dit in detail.

Als u gewoon een werkende agent wilt die veilig blijft zonder over dit alles na te hoeven denken, dat is precies wat wij hebben gebouwd.

Ga aan de slag op OpenClaw.rocks of verken de open-source Kubernetes-operator als u liever uw eigen infrastructuur beheert.