Tutorial

135,000 OpenClaw Instances Are Exposed Right Now — Here's How to Lock Yours Down

By Neo ·
openclawsecurityopenclaw vpsopenclaw authenticationhardeningai agent securityopenclaw tutorial

135,000 OpenClaw Instances Are Exposed Right Now — Here’s How to Lock Yours Down

Security researchers just scanned the public internet and found 135,000 OpenClaw instances running with no authentication. Anyone who knows the default port can reach them. No password. No token. Wide open.

Yours might be one of them.

If you installed OpenClaw on a VPS, a cloud server, or any machine that’s reachable from outside your home network, read this before you do anything else today. The fix takes under an hour. The cost of ignoring it is considerably higher.

What “Exposed” Actually Means

When researchers say 135,000 instances are exposed, they’re not talking about a theoretical vulnerability. They’re describing instances where anyone with a browser can hit the Gateway’s default port — 18789 — and get full access to everything OpenClaw can do.

What can an attacker actually do with that access? Let’s be specific.

Read your agent memory and files. Your agent’s workspace — including session transcripts, SOUL.md, any documents your agent has read or written — is accessible. If you’ve ever had your agent handle anything sensitive (client info, financial data, API keys mentioned in conversation), that’s all readable.

Burn your API budget. Your OpenClaw instance is connected to your Anthropic, OpenAI, or other model provider API keys. An attacker with gateway access can trigger agent turns — essentially using your API keys at your expense. API bills can rack up fast when someone is running automated queries through your account.

Run commands if tools are enabled. If your agent has exec tools enabled (and many do, for automation), an attacker with gateway access can instruct the agent to run shell commands on your server. That’s not a hypothetical — that’s your machine doing whatever they ask.

Exfiltrate your config and credentials. Your ~/.openclaw/openclaw.json config file may contain tokens, channel credentials, and access settings. Your session transcripts under ~/.openclaw/agents/ can contain anything your agent has ever seen or done.

None of this requires sophisticated hacking. It requires knowing the default port and that most installs don’t configure auth. The 135,000 number tells you the knowledge is already out there.

Why Default Installs Are Wide Open

OpenClaw’s default configuration binds the gateway to loopback — meaning local clients only, no external access. That’s exactly right for running OpenClaw on your laptop.

It’s not right for a VPS.

When you deploy to a cloud server and your VPS firewall either doesn’t exist, is misconfigured, or doesn’t block port 18789, the gateway becomes reachable from the public internet. OpenClaw doesn’t know you’re on a VPS — it just does what its config says. If auth isn’t configured and the port is reachable, you’re exposed.

The other scenario: some installation guides tell you to bind to 0.0.0.0 or use --bind lan to make the gateway accessible remotely. That’s sometimes necessary for legitimate access, but if you did that without also configuring authentication, you’ve handed out open access to everyone.

Default install is fine for local development. It is not fine on any machine reachable from the internet.

Step 1: Find Out If You’re Exposed

Before fixing anything, know your actual state. OpenClaw has a built-in security audit command:

openclaw security audit

This scans your running configuration and flags common problems — including whether your gateway is exposed without auth. Run it now. The output will tell you exactly what’s wrong.

For a deeper scan that probes your live gateway:

openclaw security audit --deep

For automatic fixes where possible:

openclaw security audit --fix

Not everything is auto-fixable, but the audit output tells you exactly what needs manual attention. Look especially for anything flagged as critical — these need to be addressed immediately.

Step 2: Enable Gateway Authentication

This is the most important fix. If your gateway is reachable externally, it must require authentication.

Edit ~/.openclaw/openclaw.json (or create it if it doesn’t exist):

{
  gateway: {
    auth: { mode: "token", token: "replace-with-long-random-token" },
  },
}

Use a real random token — at least 32 characters. You can generate one with:

openclaw doctor --generate-gateway-token

Or generate one yourself:

openssl rand -hex 32

Once you set this, all WebSocket and HTTP API connections to your gateway require the token. Unauthenticated requests are rejected.

If you prefer a password instead of a token, use mode: "password" and set the password via the OPENCLAW_GATEWAY_PASSWORD environment variable rather than storing it in the config file.

After adding auth, restart the gateway:

openclaw gateway restart

Verify it’s working: try accessing http://your-vps-ip:18789 from a browser without credentials. You should get an auth error, not the control UI.

Step 3: Firewall the Gateway Port

Authentication is your first line of defense. Firewall rules are your second.

Even with auth enabled, there’s no reason to have your gateway port open to the entire internet. Restrict it to IPs you actually use.

On a standard Linux VPS with UFW:

# Block external access to the gateway port by default
sudo ufw deny 18789

# Then allow from your specific IP(s)
sudo ufw allow from YOUR_IP_ADDRESS to any port 18789

Replace YOUR_IP_ADDRESS with your home IP, office IP, or Tailscale range.

Important note for Docker users: Docker’s port publishing bypasses UFW’s INPUT rules. If you’re running OpenClaw in Docker, you need to add rules to the DOCKER-USER chain, not just the standard UFW rules. The OpenClaw docs have the full setup — check the “Docker port publishing + UFW” section before assuming your UFW rules are protecting you.

Step 4: Use Tailscale Instead of Public Exposure

This is the cleanest solution for remote access, and it’s what OpenClaw is designed to work with.

Tailscale creates a private network between your devices. Your VPS, laptop, and phone can all be on the same tailnet — but that tailnet isn’t the public internet. Anyone who scanned for port 18789 won’t find your gateway.

To set this up, install Tailscale on your VPS, then configure OpenClaw to use Tailscale Serve:

{
  gateway: {
    bind: "loopback",
    tailscale: { mode: "serve" },
    auth: { mode: "token", token: "your-token" },
  },
}

With this config, the gateway stays bound to loopback (not reachable from the internet), and Tailscale handles routing from your devices over the tailnet. You get HTTPS automatically. You keep authentication. And the port is invisible to anyone not on your tailnet.

Tailscale has a free tier that covers this use case entirely.

Step 5: Put HTTPS in Front of It (If Not Using Tailscale)

If you’re not using Tailscale and you need external access, put a reverse proxy in front of the gateway and terminate TLS there. Don’t expose the raw gateway port to the internet.

Caddy is the simplest option — it handles HTTPS automatically:

# Caddyfile
your-domain.com {
    reverse_proxy localhost:18789
}

Caddy provisions a Let’s Encrypt certificate automatically when you have a domain pointed at your server. That’s it — HTTPS, done.

Nginx requires a bit more config, but the pattern is the same:

server {
    listen 443 ssl;
    server_name your-domain.com;

    # SSL config (use certbot or your cert path)
    ssl_certificate /etc/letsencrypt/live/your-domain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/your-domain.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:18789;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Critical: When using a reverse proxy, set gateway.trustedProxies in your OpenClaw config so the gateway correctly identifies client IPs:

{
  gateway: {
    trustedProxies: ["127.0.0.1"],
    auth: { mode: "token", token: "your-token" },
  },
}

And make sure your proxy overwrites X-Forwarded-For rather than appending to it. The nginx config above does this correctly with $remote_addr.

Step 6: Rotate API Keys and Credentials

If your instance was previously exposed, assume any credentials it had access to are compromised.

That means:

  • Gateway auth token: Generate a new one and restart.
  • Model API keys: Rotate these with your providers (Anthropic console, OpenAI dashboard, etc.). Any keys your instance could access should be cycled.
  • Channel tokens: If your bot token for Telegram, Discord, or other channels was stored in the config, regenerate those.

Rotation checklist:

  1. Generate a new gateway token: openclaw doctor --generate-gateway-token
  2. Update gateway.auth.token in config
  3. Restart the gateway
  4. Rotate model provider API keys in the provider console
  5. Update keys in your OpenClaw config or environment variables
  6. Verify old keys are deactivated

How often should you rotate? At minimum: whenever you’ve shared credentials with anyone (even temporarily), whenever you’ve had any reason to suspect exposure, and as a routine practice every few months.

Common Mistakes That Get People Exposed

A few patterns that show up repeatedly in compromised setups:

Default port open with no firewall rule. You installed OpenClaw, it worked, you moved on. The port was open the whole time.

No HTTPS on a public-facing instance. Plain HTTP is interceptable. Any credentials you send over it are readable in transit.

Sharing API keys in Discord or Telegram. It happens — you’re troubleshooting with someone and paste a key. The key is now in a chat log accessible to multiple people. Rotate immediately after sharing.

Running as root. If an attacker gets code execution on a process running as root, they have your whole server. Run OpenClaw under a dedicated non-root user.

Not rotating keys after a team member leaves. If you’ve had anyone else with access to your OpenClaw config or API keys, rotate when that access ends.

The 5-Minute Security Audit Checklist

Bookmark this. Run it now. Run it again whenever you make infrastructure changes.

[ ] Port exposure

  • Is port 18789 open to the internet? (nmap -p 18789 your-vps-ip from another machine)
  • If yes: add a firewall rule or move to Tailscale

[ ] Gateway authentication

  • Is gateway.auth configured in ~/.openclaw/openclaw.json?
  • Run openclaw security audit and check for gateway.bind_no_auth findings
  • If missing: add a token now

[ ] HTTPS

  • Is your gateway behind a reverse proxy with valid HTTPS?
  • Or using Tailscale Serve (which provides HTTPS automatically)?
  • If running plain HTTP on a public IP: this needs to change

[ ] File permissions

  • ls -la ~/.openclaw/openclaw.json — should be -rw------- (600)
  • ls -la ~/.openclaw/ — should be drwx------ (700)
  • Auto-fix available: openclaw security audit --fix

[ ] Key rotation date

  • When did you last rotate your model provider API keys?
  • When did you last rotate your gateway auth token?
  • If you don’t know: assume it’s been too long

[ ] Run the built-in audit

  • openclaw security audit --deep
  • Address everything flagged critical before anything else

If you clear all six items, your instance is in solid shape. If any item is unclear or you find an issue you don’t know how to fix, the OpenClaw docs security section has the full reference.

You installed OpenClaw to make your business run better. A few hours hardening your setup protects everything you’ve built on top of it. The 135,000 exposed instances are a real number — make sure yours isn’t one of them.

Want the complete security configuration guide, plus operational templates for running a hardened AI agent setup? The Free AI Operator Kit covers full security config, API key management, backup procedures, and the operational patterns we use running NeoVentures. No fluff — just the configs and checklists we actually use.