DEV Community

Cover image for 220,000+ OpenClaw Instances Are Exposed. Here's How to Check Yours.
Mehul Bhardwaj
Mehul Bhardwaj

Posted on

220,000+ OpenClaw Instances Are Exposed. Here's How to Check Yours.

#ai #security #agents #openclaw

Security researchers have been scanning for exposed OpenClaw instances since January 2026. The numbers vary by methodology: Penligent found over 220,000, SecurityScorecard identified 135,000, Censys tracked growth from 1,000 to 21,000+ in a single week. Microsoft's security blog concluded that "for most environments, the appropriate decision may be not to deploy it."

Most of these instances are running without TLS. Many are still vulnerable to ClawJacked (CVE-2026-25253, CVSS 8.8), which allowed any webpage you visited to silently brute-force the gateway token over localhost with no rate limiting.

I've been reviewing public configs and deployment guides. Three misconfigs show up in the majority of them, and they're all fixable in minutes.

The exposure surface

OpenClaw's default config binds the gateway to 0.0.0.0:18789. If you install it on a VPS and don't touch the network settings, the gateway is public. There's no warning during setup. The docs mention it, but not where people look.

What this means in practice:

  • Gateway token brute-force. ClawJacked (CVE-2026-25253, CVSS 8.8) allowed any webpage you visited to brute-force the gateway token. No rate limiting. No CORS. Patched in v2026.1.24-1, but the fix requires updating. Persistent services that nobody actively maintains tend to drift.

  • Unencrypted traffic. Without TLS, everything between the browser and the agent travels in plaintext. API keys, model responses, user data. On a shared network, that's trivial to intercept.

  • Supply chain. ClawHavoc in January 2026: researchers found 824 malicious skills on ClawHub out of roughly 10,700 total. Clawdex, the main community scanner, was catching under 10% of them (Oathe's independent audit confirmed this). If your instance auto-installs recommended skills, you're trusting a supply chain that has already been compromised.

The three configs most people get wrong

I've reviewed hundreds of openclaw.json files from public repos, Docker Compose setups, and deployment guides. Three misconfigs show up in the majority of them.

1. Gateway binding

Default: binds to all interfaces (0.0.0.0:18789)
What it should be: loopback (127.0.0.1 only)

If you're running behind a reverse proxy or tunnel, the gateway should never be reachable directly. The bind key accepts loopback, lan, tailnet, or custom.

{
  "gateway": {
    "bind": "loopback",
    "port": 18789
  }
}
Enter fullscreen mode Exit fullscreen mode

2. The three proxy/tunnel flags

If you're running behind a reverse proxy or Cloudflare Tunnel, you need three flags under gateway.controlUi. Not at the root level. Not as dot-notation keys. Nested JSON only.

{
  "gateway": {
    "controlUi": {
      "dangerouslyDisableDeviceAuth": true,
      "dangerouslyAllowHostHeaderOriginFallback": true,
      "allowInsecureAuth": true
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

Most guides mention two of these. The third, dangerouslyDisableDeviceAuth, is the one that causes the disconnected (1000): no reason error in the browser. It disables CLI-based device pairing, which only works with local machine access. Behind a proxy, there's no local CLI, so the auth loop times out silently.

The flag names sound dangerous. They're not, if you have a proxy handling auth in front. Without a proxy, don't set them.

3. TLS termination

If your reverse proxy handles TLS (it should), the gateway can run without its own certificate. But the connection between proxy and gateway must stay on loopback. If the proxy runs on a different host than the gateway, you need TLS on both hops.

[Browser] →HTTPS→ [Proxy (TLS)] →HTTP→ [Gateway (127.0.0.1:18789)]
Enter fullscreen mode Exit fullscreen mode

This only works when proxy and gateway share the same host. Most single-VPS setups qualify.

How to check yours

Run these checks on any instance:

1. Port exposure check:

# From outside your network
nmap -p 18789 your-server-ip
# If it shows "open", your gateway is public
Enter fullscreen mode Exit fullscreen mode

2. Config audit:

# On the server
cat ~/.openclaw/openclaw.json | grep -E "bind|dangerously|allowInsecure"
Enter fullscreen mode Exit fullscreen mode

3. Version check:

openclaw --version
# Anything before v2026.1.24-1 is vulnerable to ClawJacked
Enter fullscreen mode Exit fullscreen mode

I also built a free scanner that runs these checks and a few more (skill supply chain, known CVE patterns, config analysis): https://vesselofone.com/tools/security-check. It runs against your instance URL and returns a report. No data stored, no signup required.

TL;DR

  • Set gateway.bind to "loopback", not the default (all interfaces)
  • Set the three gateway.controlUi flags if behind a proxy or tunnel
  • TLS terminate at the proxy, keep gateway on loopback
  • Update to v2026.1.24-1 or later (ClawJacked fix)
  • Audit installed skills (ClawHavoc found 824 malicious ones on ClawHub)
  • Run a port scan from outside your network to verify nothing is exposed

Most of these take five minutes. The gap between "it works" and "it's not actively exploitable" is three config lines.

Top comments (0)