30,000 OpenClaw Instances Are Running Without Authentication

By Linas Valiukas · March 10, 2026

In February 2026, security researchers scanning the public internet found over 30,000 OpenClaw instances running with no authentication. No password. No access code. No login screen. Anyone with the IP address could open the dashboard, read every conversation, send messages through connected accounts, and in many cases execute arbitrary commands on the host machine. This isn't a vulnerability in OpenClaw's code. It's the default configuration.

How this happens

OpenClaw ships with authentication disabled. The ACCESS_CODE environment variable is empty by default. If you install OpenClaw, start it with Docker, and open port 3210 — congratulations, you have a publicly accessible AI agent with full permissions. No warning. No prompt asking you to set a password. It just works, for everyone.

Most quick-start guides skip the authentication step. The official Docker one-liner gets the server running in 30 seconds. Security configuration is mentioned in a separate page that many users never read. The result: thousands of people who followed a tutorial, got OpenClaw working, connected their WhatsApp or Telegram, and moved on — leaving the front door wide open.

What an attacker can do with your exposed instance

An unauthenticated OpenClaw instance isn't just a data leak. It's a fully functional command center for whoever finds it. Here's what's accessible:

• Full conversation history. Every message you've sent and received through connected platforms. Personal conversations, business discussions, passwords shared in chat — all readable.
• Send messages as you. An attacker can compose and send messages through your WhatsApp, Telegram, Slack, or Discord accounts. Your contacts see messages from you. Social engineering at scale, using your identity.
• Access your LLM API keys. Your OpenAI, Anthropic, or other API keys are stored in the configuration. An attacker can extract them and run up charges on your account. Some users have reported surprise bills in the hundreds of dollars.
• Install malicious skills. OpenClaw's skill system lets users add new capabilities. An attacker can install skills that exfiltrate data, establish persistence, or turn your server into part of a botnet.
• Execute shell commands. If OpenClaw is running outside the sandbox (which many guides recommend for "full functionality"), the built-in terminal skill gives direct shell access to the host machine. Game over.

This isn't theoretical. The ClawHavoc campaign discovered in early 2026 found roughly 800 malicious skills in the OpenClaw skills registry — about 20% of all published skills. Some were designed specifically to target exposed instances.

Why the defaults are dangerous

Secure defaults are a solved problem in software engineering. SSH disables root login by default. PostgreSQL only listens on localhost. Firewalls deny by default. OpenClaw chose the opposite approach: everything open, lock it down yourself.

The reasoning is understandable — low friction for local development. But OpenClaw isn't a database or a build tool. It's an AI agent connected to your personal messaging accounts with the ability to act on your behalf. The blast radius of a misconfiguration is enormous. And the user base skews toward non-technical people who are unlikely to know that port 3210 needs a firewall rule.

Microsoft's security team put it bluntly in their February 2026 advisory: OpenClaw is "not appropriate to run on a standard personal or enterprise workstation" and should only be evaluated in fully isolated virtual machines. CrowdStrike, Cisco, and Sophos published similar warnings.

How to check if your instance is exposed

If you're self-hosting OpenClaw, run these checks right now:

1. Test from outside your network

From your phone (on mobile data, not WiFi) or any external machine, open http://YOUR_SERVER_IP:3210 in a browser. If you see the OpenClaw interface without being asked for a password, you're exposed. Shut it down immediately and follow the hardening steps below.

2. Check your environment variables

Look at your docker-compose.yml or .env file. If ACCESS_CODE is empty, commented out, or missing entirely, authentication is disabled.

3. Search for yourself on Shodan

Go to Shodan or Censys and search for your server's IP address. If port 3210 appears in the results, internet-wide scanners have already indexed your instance. Assume it's been found by someone who isn't you.

How to lock down a self-hosted instance

If you've confirmed your instance is exposed — or you're not sure — take these steps immediately:

Step 1: Set an access code

Add ACCESS_CODE=your-strong-password-here to your environment variables and restart the container. Use a long, random string — not "password123" or "openclaw". This is the minimum viable security measure.

Step 2: Firewall port 3210

Don't expose port 3210 to the public internet at all. Use ufw or your cloud provider's security group to block inbound traffic on that port. Access the dashboard through a VPN or SSH tunnel instead.

Step 3: Put it behind a reverse proxy

Use Nginx or Caddy as a reverse proxy with HTTPS. This adds TLS encryption (so your access code isn't sent in plaintext) and gives you access logging. A Cloudflare Tunnel is another option that avoids opening any ports at all.

Step 4: Enable sandboxing

Run OpenClaw in sandboxed mode. This restricts what skills can do — no arbitrary shell commands, no filesystem access outside designated directories. Yes, some skills won't work. That's the point.

Step 5: Rotate your credentials

If your instance was exposed, assume your API keys are compromised. Rotate your OpenAI, Anthropic, and any other API keys immediately. Review your connected messaging accounts for messages you didn't send. Check your LLM billing dashboard for unexpected usage.

The CVE that made it worse

As if open-by-default wasn't enough, CVE-2026-25253 (CVSS 8.8) disclosed a remote code execution vulnerability in OpenClaw's gateway layer. Even instances with authentication enabled were vulnerable — an attacker could bypass the access code entirely and gain full control of the gateway. The patch shipped quickly, but self-hosted users who don't actively monitor for updates were left exposed for weeks.

This is the core problem with self-hosting security-critical software: the fix exists, but it only helps if you apply it. On our infrastructure, we deployed the patch across all managed instances within hours of disclosure. Self-hosted users had to notice the advisory, pull the new image, test it, and redeploy — assuming they even knew the CVE existed.

Why this keeps happening

OpenClaw has 247,000 GitHub stars. It's been called "the most important software release probably ever" by the CEO of Nvidia. Governments are subsidizing its adoption. Tencent is integrating it into WeChat.

The hype is moving faster than the security. People who have never administered a Linux server are spinning up VPS instances to run an AI agent that has full access to their personal messaging accounts and, potentially, their entire machine. The gap between OpenClaw's capability and its security defaults is the problem. The software can do almost anything. And by default, anyone can tell it to.

The managed hosting alternative

This is not a subtle pitch. If you're running an exposed OpenClaw instance right now, you have two options: learn infrastructure security and maintain it yourself indefinitely, or let someone else handle it.

TryOpenClaw.ai runs each instance in an isolated environment with authentication enforced, network policies configured, automatic security updates, and no exposed ports. You don't need to know what a firewall rule is. You don't need to check Shodan. You don't need to read CVE advisories.

Self-hosting is a legitimate choice for people who understand the responsibilities. But if you set up OpenClaw by following a YouTube tutorial and you're not sure whether your instance is exposed — it probably is. And the consequences of getting it wrong are not theoretical.

Frequently asked questions

How do I check if my OpenClaw instance is exposed?

From a device outside your network, open http://YOUR_SERVER_IP:3210 in a browser. If you see OpenClaw's interface without a login prompt, it's exposed. Also search your server's IP on Shodan — if port 3210 is listed, scanners have already found it.

What can an attacker do with my exposed instance?

Read your conversations, send messages as you through connected platforms, steal your LLM API keys, install malicious skills, and potentially gain shell access to the host machine. It's full access to everything OpenClaw can do — which, by design, is a lot.

Does OpenClaw have authentication enabled by default?

No. Authentication is disabled by default. You must set the ACCESS_CODE environment variable manually. Many setup guides skip this step.

Is managed hosting safer than self-hosting?

Self-hosting can be equally secure if configured correctly. The problem is that 30,000+ instances prove many people don't configure it correctly. Managed hosting removes the possibility of misconfiguration by handling authentication, isolation, patching, and monitoring for you.