Over 135,000 OpenClaw instances are exposed on the internet. A critical vulnerability allows one-click remote code execution through any browser. Researchers have found over 1,100 malicious skills distributing Atomic Stealer on ClawHub. Microsoft published a blog post titled “Running OpenClaw Safely” that opens by noting that “for most environments, the appropriate decision may be not to deploy it.” Belgium’s national cybersecurity center issued a government advisory. Cisco called personal AI agents like OpenClaw “a security nightmare.”

This is not FUD. These are facts from independent security researchers, enterprise vendors, and government agencies. If you run an OpenClaw instance, this matters to you.

What went wrong

OpenClaw was designed for localhost. You install it on your machine, talk to it through a local web interface, and it does things on your behalf. The security model assumed that the person accessing the interface was the person sitting at the keyboard.

Then OpenClaw went from 9,000 to over 200,000 GitHub stars in a matter of weeks. People deployed it on VPS machines, exposed it to the internet, and connected it to their messaging channels. The localhost assumption broke at scale. (We covered the full spectrum of deployment options and their security trade-offs in a separate guide.)

CVE-2026-25253: one-click remote code execution

The most severe vulnerability is CVE-2026-25253, scored CVSS 8.8. OpenClaw did not validate WebSocket origin headers. Here is how the attack works:

  1. The victim visits a malicious webpage (or a page with a malicious ad).
  2. JavaScript on that page opens a WebSocket connection to localhost:18789, the default OpenClaw port.
  3. Because the browser is on the same machine, the connection bypasses any firewall rules.
  4. The attacker exfiltrates the gateway authentication token through the WebSocket.
  5. With the token, the attacker has full control: shell access, file read/write, and command execution.

Binding to localhost does not help. The attack pivots through the victim’s own browser. SOCRadar’s analysis walks through the full chain.

Malicious skills and supply chain attacks

Researchers found 341 malicious skills on ClawHub in early February. That number has since grown to over 1,100. The ClawHavoc campaign distributes Atomic Stealer through skills that look legitimate but contain hidden command execution steps. Skills are Markdown files. A hidden instruction that says “run this shell command” is easy to embed and hard to spot.

On February 17, the Cline supply chain attack took things further. A compromised npm token was used to push a version of the Cline CLI that silently installed OpenClaw on developer machines. The attack targeted the build pipeline itself.

Researchers have now disclosed six additional vulnerabilities in OpenClaw’s core, including CVE-2026-27001. The OWASP Top 10 for Agentic Applications now lists many of these patterns as top risks. As Conscia’s analysis puts it, this is a full-blown security crisis.

Why a gateway token is not enough

OpenClaw’s built-in authentication is a static token. You set it once, and every request must include it. It is better than nothing. But it has fundamental limitations.

Static tokens do not expire. If a token leaks (through CVE-2026-25253, through logs, through a malicious skill reading environment variables), the attacker has permanent access until you notice and rotate it manually.

Static tokens cannot be scoped. The gateway token grants full access. There is no way to give someone read-only access or limit what an authenticated session can do.

Static tokens cannot be tied to a user. If three people share a token, you have no audit trail for who did what.

Most VPS deployment guides tell you to put OpenClaw behind nginx with basic auth. That is better, but still a static credential. If someone captures it (network sniffing on an unencrypted connection, a compromised reverse proxy config, a leaked .htpasswd file), they are in.

The fundamental problem is deeper: authentication happens inside the application. If the application has a vulnerability, authentication can be bypassed. CVE-2026-25253 demonstrated this exactly. The gateway token existed. The vulnerability extracted it before the application even got a chance to verify it.

This is why we built OpenClaw.rocks with authentication at the proxy layer. The sections below explain the architecture in detail. If you just want a secure instance without building this yourself, see our plans.

How we secure the gateway

At OpenClaw.rocks, authentication happens at the proxy layer, before the request ever reaches the OpenClaw pod. This is a structural difference, not just a configuration difference.

Here is the three-layer architecture.

Layer 1: Signed gateway cookies (HMAC-SHA256)

When you access your OpenClaw instance through the OpenClaw.rocks dashboard, the server generates a signed cookie. The format is:

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

The cookie has a 4-hour TTL and auto-refreshes every 45 minutes. It is path-scoped to /gw/{instanceId}, so one cookie cannot be used to access a different instance. It is HttpOnly (JavaScript cannot read it), Secure (only sent over HTTPS), and SameSite=Lax (not sent on cross-origin requests). The HMAC is verified using timing-safe comparison to prevent timing attacks.

Even if someone intercepts the cookie value, they cannot forge a new one without the signing secret. And the cookie itself contains no credentials that grant access to OpenClaw directly.

Layer 2: Traefik ForwardAuth

Every request to an OpenClaw instance passes through Traefik, our reverse proxy. Before forwarding the request, Traefik calls an auth-gate endpoint that verifies the signed cookie.

This is pure HMAC verification. Zero database calls. Zero network requests to Supabase or any other service. The decision is made in microseconds.

If the cookie is invalid, expired, or missing, the request is rejected at the proxy layer. The request never reaches OpenClaw. This is the key difference. In a typical setup, OpenClaw itself must decide whether to allow or reject a request. If OpenClaw has a vulnerability in its authentication logic, an attacker can slip through. In our setup, OpenClaw never sees unauthenticated traffic.

Layer 3: Gateway token injection

Every OpenClaw instance has a built-in gateway token. This is the same token you would configure yourself if you self-hosted. The difference is how it gets to the pod.

In a typical self-hosted setup, you paste the token into a config file, maybe store it in an environment variable, and hope it never leaks. Your browser needs to send it on every request, which is exactly how CVE-2026-25253 exfiltrated it.

In our setup, a cryptographically random 32-byte token is generated at instance creation and stored as a Kubernetes Secret. Traefik injects it as an Authorization header on every forwarded request. The browser never sees it. It never appears in a config file you can accidentally commit. It never travels over a WebSocket that a malicious page can hijack. The token exists, but it lives entirely inside the cluster, moving only between Traefik and the pod.

Why this architecture blocks CVE-2026-25253

The CVE-2026-25253 attack chain exfiltrates the gateway token via WebSocket. Let’s walk through what happens when that attack targets an OpenClaw.rocks instance:

  1. The attacker’s JavaScript tries to open a WebSocket to the OpenClaw pod.
  2. The connection hits Traefik first. Traefik checks for the signed cookie.
  3. The malicious page is on a different origin. The SameSite=Lax cookie is not sent on cross-origin WebSocket connections. The request is rejected.
  4. Even if the cookie were somehow attached, the attacker’s page cannot read it (HttpOnly). There is nothing to exfiltrate.
  5. Even if the cookie leaked, it does not contain the bearer token. The bearer token is injected by Traefik, never exposed to the browser. The attacker cannot reconstruct it.

There is nothing to steal because the browser never holds the real credentials. The attack surface that CVE-2026-25253 exploits simply does not exist.

OpenClaw security checklist for self-hosters

Not everyone wants managed hosting, and that is fine. If you run your own OpenClaw instance, here is a practical checklist for 2026.

Is your gateway auth token enabled? Run openclaw doctor to check. If gateway auth is disabled, anyone who can reach port 18789 controls your agent and everything it has access to.

Is your instance behind a reverse proxy with TLS? Plain HTTP means anyone on the network path can read your gateway token in transit. Use nginx, Caddy, or Traefik with a valid TLS certificate. Let’s Encrypt is free.

Are you on the latest version? CVE-2026-25253 was patched in v2026.1.29. CVE-2026-27001 was patched in v2026.2.15. If you are running an older version, update now. The Adversa AI hardening guide covers additional steps.

Have you audited your installed skills? The ClawHavoc campaign targeted ClawHub specifically. Check every skill you have installed. If you did not install it yourself, remove it and verify the source.

Is your reverse proxy validating WebSocket origins? This is the specific vector CVE-2026-25253 exploited. Your reverse proxy should reject WebSocket upgrade requests from unexpected origins. OpenClaw’s security documentation has configuration examples.

Does your auth happen before or after the request reaches OpenClaw? This is the question that matters most. If OpenClaw handles its own authentication, a vulnerability in OpenClaw can bypass it. If your reverse proxy handles authentication, the request never reaches OpenClaw unless it is already verified.

What we do not solve

Honesty matters here. Proxy-level authentication solves gateway security. It does not solve everything.

Prompt injection is an application-layer problem. A cleverly crafted message can potentially trick the agent into taking unintended actions. This is an active area of research across the entire AI industry, and no hosting provider can fully prevent it today.

Malicious skill behavior runs inside the agent’s context. If you install a skill that exfiltrates data through an allowed HTTPS egress, proxy auth cannot stop that. What our infrastructure does is contain the blast radius: each instance runs in its own Kubernetes pod with network isolation, dropped capabilities, seccomp, and a read-only root filesystem. A compromised agent cannot reach other agents or the host system. The Kubernetes operator enforces these defaults for every instance.

LLM provider trust depends on your plan. If you bring your own API keys (Light plan), your conversations pass through whichever provider you configure, and their privacy policy applies. On the Pro plan, we route traffic through our own AI gateway with pre-configured providers. You do not need to hand your API keys to an OpenClaw instance or trust that a third-party key is stored securely. The gateway manages provider credentials on your behalf, and you never see or handle them directly.

Security is layers. We handle the infrastructure layers. The application-layer challenges are real and worth understanding.

Security is an architecture decision

The OpenClaw security crisis is not about one CVE or one batch of malicious skills. It is about a tool designed for localhost being deployed on the internet by hundreds of thousands of people, with authentication that happens inside the application it is supposed to protect.

Moving authentication to the proxy layer is not a feature. It is an architecture decision. It means that when the next OpenClaw CVE drops (and it will), authenticated requests are still verified before they touch the application. The attack surface is structurally smaller.

We made that decision on day one. Every OpenClaw.rocks instance runs behind signed cookies, ForwardAuth verification, and per-instance bearer tokens. No gateway tokens in the browser. No static credentials to exfiltrate. No authentication logic inside the vulnerable application.

If you want to read more about how we deploy OpenClaw on Kubernetes with full security hardening, the deployment guide covers it in detail.

If you just want a running agent that stays secure without thinking about any of this, that is what we built.

For a quick overview, read our FAQ on whether OpenClaw is safe and whether open source software is safe to use.

Get started at OpenClaw.rocks or explore the open-source Kubernetes operator if you prefer to run your own infrastructure.