135,000 exposed: the real security risk of self-hosting OpenClaw
OpenClaw is impressive software. It's also one of the most widely-exposed applications on the internet right now — and most people running it don't realize it.
The numbers
Bitsight found 135,000+ self-hosted OpenClaw instances publicly accessible on the internet. Over 15,000 are vulnerable to remote code execution. A security audit found 512 vulnerabilities, 8 of them critical.
Cisco called self-hosted OpenClaw a "security nightmare." Kaspersky flagged it as unsafe. Gartner said the design is "insecure by default." None of this is speculation — it's documented and actively being exploited.
The default config is the problem
Install OpenClaw and the gateway binds to 0.0.0.0 with auth disabled. Anyone on your network — or the internet if your firewall has any gaps — can send commands to your AI assistant.
Most users never change this. Most tutorials don't mention it.
The ClawHavoc supply chain attack
In February 2026, security researchers found what they called the ClawHavoc campaign: 341 malicious skills uploaded to ClawHub, OpenClaw's skill marketplace.
They looked legitimate. Descriptions, icons, star ratings. They installed quietly during normal clawhub install commands.
Self-hosted users who updated skills during this period likely had their API keys, gateway tokens, and file system contents exfiltrated.
ClawJacked: the WebSocket hijack
The same month, researchers published details on "ClawJacked" — malicious websites that can hijack a local OpenClaw instance via WebSocket. Local gateways often run without origin checking.
Visit a malicious link, and your entire OpenClaw instance — conversations, API keys, connected integrations — can be taken over without any visible sign.
The one-click RCE
The most severe CVE let attackers achieve full remote code execution with a single HTTP request to an exposed gateway. The attack exploited an unvalidated gatewayUrl parameter to steal auth tokens and run privileged shell commands.
No user interaction required.
What to do if you're self-hosting
If your instance is reachable from the internet (test: does http://your-ip:3000 load without a password?):
GATEWAY_TOKEN in your .env — immediatelyHow MyOpenClaw.cloud is different
Every instance runs in an isolated Fly Machine with no public port exposure. The only access is through our authenticated gateway.
Skills are pinned to verified versions with SHA-256 hashes. The ClawHavoc attack didn't reach our users. OpenClaw updates are tested by us before they reach your instance. All API keys and secrets are encrypted with AES-256-GCM.
You don't manage any of this. It's just done.
Who should still self-host?
Self-hosting makes sense if you have real ops experience and can correctly configure a firewall, reverse proxy, and auth — or if you need air-gapped infrastructure, want to run local models via Ollama, or genuinely enjoy the ops work.
If you don't know what 0.0.0.0 means, don't self-host.
The honest bottom line
OpenClaw was optimized for getting started quickly, not for running safely in production. That's a reasonable design tradeoff. The problem is that most users don't know they're making a security decision when they paste the install command.
If you're self-hosting, audit your setup today. If you're just getting started, a managed service removes the entire attack surface.
Start your secure, managed OpenClaw instance →