OpenClaw security: a checklist after 40,000 exposed servers

Most of the OpenClaw servers found in this year's internet scans weren't broken by some clever AI attack. They were reachable because of ordinary defaults and shortcuts: a gateway listening on every network interface, a weak login, an install that had missed its security fixes. Each of those takes minutes to fix, and the checklist below puts them in the order that removes the most risk first.

The checklist at a glance

1. Bind the gateway to 127.0.0.1 and never publish its raw port.
2. Reach it by SSH tunnel, Tailscale, or a TLS proxy with its own login.
3. Use a long, random gateway token.
4. Allowlist the chat user IDs allowed to talk to the bot.
5. Give each agent its own spend-capped API key, and rotate it if it leaks.
6. Turn off tools the job doesn't need and sandbox the rest.
7. Vet skills and plugins like any software you install.
8. Confirm before the agent acts on instructions from web pages, emails or files.
9. Update on a schedule, with a backup and a way back.
10. Back up the agent's state and test a restore.
11. Keep logs, and alert on spend spikes or config changes.
12. Run it as a non-root user in a container.
13. Firewall everything except SSH and HTTPS, and use key-only SSH.
14. If you were exposed: contain, rotate every secret, read the logs, rebuild.

Config keys and commands below follow each project's docs as of November 2026.

What the scans found, and who found it

OpenClaw went viral in January 2026 and was renamed twice in a few days at the end of the month (Clawdbot, then Moltbot, then OpenClaw). Scanners noticed almost at once.

Censys published first. On 31 January its researcher Silas Cutler counted 21,639 exposed instances by matching the control page's title, up from about 1,000 less than a week earlier. Most still asked for a token before the panel could be used, so exposed didn't automatically mean open.

On 9 February SecurityScorecard's STRIKE team reported 24,034 instances from a title search and 40,214 confirmed by favicon fingerprinting, 23,505 of them showing an active control panel. From the product name each page displayed, STRIKE estimated that 78% likely ran versions from before the late-January security fixes. Its live dashboard kept climbing: by the time The Register covered it that afternoon the count was above 135,000, with more than 50,000 flagged as vulnerable to an already patched remote code execution bug. Bitsight reported the same day: more than 30,000 distinct instances in daily scans between 27 January and 8 February.

These numbers don't agree, and you shouldn't expect them to. Each team used its own fingerprints and its own idea of "exposed", on different days, while instances came and went. Even one study varies by where you read it: STRIKE's dashboard header listed 42.9K unique IPs, while Infosecurity Magazine's coverage of the same research gave 28,663. The May figures in the table come with a warning that scans can't see whether authentication sits in front. What every source supports is simpler: tens of thousands of agent gateways were answering on the public internet.

Why so many were reachable

Sources even disagree on the default. STRIKE wrote that "out of the box, OpenClaw binds to 0.0.0.0:18789", meaning every interface; Censys wrote that it listens locally. OpenClaw's current docs reconcile the two: a host install binds to loopback, while inside a container the default resolves to 0.0.0.0 and the gateway requires auth. Bitsight added that setup offered a LAN option as the easy route to remote access.

• Same-box reverse proxies. Bitsight describes nginx in front of a localhost-only gateway, making every request look local.
• Weak secrets. Nothing enforced complexity, and Bitsight notes a single letter was accepted. Builds before 2026.1.29 even allowed an auth mode of "none".
• Old builds. Three high-severity CVEs with public exploit code were fixed in 2026.1.29, and most exposed panels hadn't updated.
• Leaked credentials. STRIKE found API keys and gateway tokens in public GitHub repositories.

The best known of those CVEs, CVE-2026-25253 (CVSS 8.8), shows why "it's only on localhost" wasn't a full answer either. The Control UI took a gatewayUrl from the query string and connected automatically, sending the stored token along, so one click on a crafted link could hand that token to an attacker. Per the advisory, it worked even on loopback-only instances, because the victim's own browser made the connection.

Pillar Security, quoted by Bitsight, saw honeypot probes within minutes; the capable attackers skipped the AI and went straight for the gateway's WebSocket API.

Why an agent is a better prize than a web app

A compromised blog leaks a database. A compromised agent hands over everything it can reach, and keeps working while you sleep. In STRIKE's words: "when you give an AI agent full access to your computer, you give that same access to anyone who can compromise it."

• Secrets with money attached: an LLM key billed to your card, plus OAuth grants for mail or code.
• Identities. A bot token lets someone speak as your bot to everyone who trusts it.
• Tools. Shell and browser access pass to whoever controls the gateway.
• Untrusted text. Web pages and emails can carry instructions, which is why OWASP's 2025 list for LLM applications ranks prompt injection first.
• No supervision. Scheduled jobs don't wait for you to log in.

OpenClaw's own security policy starts from the same premise. The model "is not a trusted principal", so the real boundaries are auth, tool policy, sandboxing and approvals.

The checklist, item by item

1. Keep the gateway on loopback and never publish the raw port

If the port answers on the internet, scanners will find it, and your only protection becomes a token plus whatever bugs your build still has. OpenClaw host installs default to loopback; set it explicitly anyway. In Docker the gateway listens on every interface inside the container, so restrict it where the port is published. Hermes' dashboard already defaults to 127.0.0.1:9119.

// ~/.openclaw/openclaw.json (host install)
{ gateway: { bind: "loopback", port: 18789 } }

# docker-compose.yml: publish to localhost only
ports:
  - "127.0.0.1:18789:18789"

The listener should show 127.0.0.1; from outside, the port should be closed or filtered.

# on the server
ss -tlnp | grep -E '18789|9119'

# from another network
nmap -Pn -p 18789,9119 YOUR_SERVER_IP

2. Reach it through a tunnel, or a proxy that asks for a login

The safest route opens no public port. OpenClaw's security policy rules out public exposure, reverse proxies included, because the gateway "is not hardened for public exposure". It recommends an SSH tunnel or Tailscale, and the Hermes dashboard docs say the same.

ssh -N -L 18789:127.0.0.1:18789 you@your-server
# then open http://127.0.0.1:18789 in your local browser

If you still want browser access from anywhere, you're outside OpenClaw's recommended setup, so make the proxy earn its place: TLS, its own login, and an explicit trusted-proxy entry so requests stop looking local. OpenClaw's network exposure docs show the settings.

// OpenClaw: ~/.openclaw/openclaw.json
{
  gateway: {
    trustedProxies: ["10.0.0.1"],   // your reverse proxy's IP
    auth: { mode: "password" },     // password via OPENCLAW_GATEWAY_PASSWORD
  },
}

# Hermes: ~/.hermes/config.yaml
dashboard:
  public_url: "https://agent.example.com"
  trusted_proxies:
    - "172.20.0.5"

On a public Hermes hostname, the docs describe the Nous Portal OAuth provider as the one suited to internet-facing use. The username and password provider is meant for trusted networks or a VPN.

3. Use long, random gateway secrets

OpenClaw treats anyone who passes gateway auth as a trusted operator, so the token is the whole lock. Generate it rather than typing one.

openssl rand -hex 32
openclaw doctor --generate-gateway-token

# flags blank or short (under 24 chars) secrets
openclaw security audit --deep

For Hermes, the docs recommend a password hash plus a signing secret in ~/.hermes/.env, with chmod 600. Keep tokens out of screenshots and shared links.

4. Allowlist who can talk to the bot

OpenClaw's policy puts it bluntly: anyone who can operate an agent can make it do anything that agent can do. Decide who that is, by numeric user ID.

// OpenClaw: ~/.openclaw/openclaw.json
{
  channels: {
    telegram: {
      dmPolicy: "allowlist",
      allowFrom: [123456789],    // your numeric Telegram user ID
      groupPolicy: "allowlist",
    },
  },
}

# Hermes: ~/.hermes/.env
TELEGRAM_ALLOWED_USERS=123456789

OpenClaw's default DM policy is pairing, where strangers get a code that you approve with openclaw pairing approve. That's fine if you only approve people you know. Hermes denies anyone who isn't allowlisted or paired, so never set GATEWAY_ALLOW_ALL_USERS=true in production. New to the Telegram side? See the Hermes Telegram setup walkthrough.

5. Give each agent its own spend-capped API key

The February reports found API keys in public GitHub repositories and leaking through exposed control panels. One key per agent makes a leak a single revocation, and a monthly limit at the provider caps the bill if someone else spends it. Size the limit from real usage (the monthly cost breakdown helps). Never paste a key into a chat, a ticket or the agent's own conversation, because transcripts keep it. If one leaks, revoke first and replace second.

6. Turn off tools the job doesn't need

Tools turn a hijacked conversation into a shell on your server. OpenClaw's docs suggest denying control-plane tools to agents that handle untrusted content; its hardened baseline looks roughly like this:

{
  tools: {
    profile: "messaging",
    deny: ["gateway", "cron", "sessions_spawn", "sessions_send"],
    fs: { workspaceOnly: true },
    elevated: { enabled: false },
  },
}

OpenClaw can also sandbox tools, with the workspace mounted read-only or not at all (workspaceAccess: "ro" or "none"). The Hermes security docs recommend the Docker terminal backend for production gateways. On the local backend, consider approvals.mode: manual over the default smart mode, and never run --yolo on an agent that reads outside content.

7. Treat skills and plugins as code you're installing

Because that's what they are. In early February Koi Security audited 2,857 ClawHub skills and flagged 341 as malicious, 335 of them from one campaign it called ClawHavoc, as eSecurity Planet reported. A fake "prerequisite" install step delivered the Atomic macOS Stealer. OpenClaw's plugins run in-process with the gateway's own OS privileges.

• Install from sources you trust, pin versions, and read a skill's files before enabling it.
• Never paste a setup one-liner from a skill's README into a terminal.
• In OpenClaw, pin trusted plugins with plugins.allow and use security.installPolicy.

8. Don't let content turn into commands

Prompt injection has no complete fix. The OWASP mitigations that matter most here are least privilege, human approval for high-risk actions, and keeping untrusted content clearly separated.

• Split readers from actors. An inbox summarizer shouldn't be able to send mail or run commands.
• Confirm anything irreversible: payments, deletions, code pushes, messages to new recipients.
• Leave OpenClaw's unsafe-content switches off, such as hooks.gmail.allowUnsafeExternalContent.
• Use a strong model for tool-using agents; OpenClaw notes weaker tiers are easier to inject.

9. Update on a schedule, with a way back

STRIKE's 78% is the plainest lesson of February: the fixes existed, and most exposed panels lacked them. More followed. After four CVEs were fixed in OpenClaw 2026.4.22 in April, the Cloud Security Alliance told anyone on an older build to treat every credential the process could reach as potentially compromised.

openclaw update    # OpenClaw, host install
hermes update      # Hermes

# container installs
docker compose pull && docker compose up -d

Pin container image tags and change them on purpose. Back up before every update; OpenClaw's docs say to roll back by restoring that backup with its matching version. The Hermes update, backup and rollback guide covers the routine for Hermes.

10. Back up, then prove the restore works

A backup only counts once you've restored it.

openclaw backup create --verify
openclaw backup restore ./<archive>.tar.gz --target ./restore-test

OpenClaw restores into an empty directory, never in place, so a test restore is safe. Hermes keeps its state in ~/.hermes unless HERMES_HOME points elsewhere. Backups hold your keys and chat history, so encrypt them and keep a copy off the server. A monthly restore onto a scratch machine catches most surprises.

11. Keep logs and alert on the odd stuff

Probes are a given. You want to notice when someone gets further.

• OpenClaw: openclaw logs --follow. Log files default to /tmp/openclaw/, which many distros wipe on reboot, so set logging.file if you want history. Transcripts live under ~/.openclaw/agents/<agentId>/sessions/.
• Hermes: watch ~/.hermes/logs/ for unauthorized access attempts.
• Alert on spend spikes and unexpected pairing requests, and on any change to bind, auth or tool settings.
• Ship logs off the box, where an intruder can't edit them.

12. Run it as a non-root user, in a container

OpenClaw's official image runs as the unprivileged node user, and its policy suggests a read-only filesystem with capabilities dropped. Hermes' docs say never to run the gateway as root.

# adapted from OpenClaw's SECURITY.md,
# plus a localhost-only port
docker run --read-only --cap-drop=ALL \
  -p 127.0.0.1:18789:18789 \
  -v openclaw-data:/app/data \
  openclaw/openclaw:latest   # pin a version

Never mount the Docker socket into an agent container; that's root on the host by another name. One container and volume per agent stops a single compromise from reading every agent's keys.

13. Firewall everything else, and lock down SSH

Only SSH and your web ports should be reachable, and SSH should accept keys only.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80,443/tcp
sudo ufw enable

# /etc/ssh/sshd_config
PasswordAuthentication no
PermitRootLogin no

Reload sshd, and keep your current session open until a fresh key login works. One common trap: Docker writes its own iptables rules for published ports, so a port published on all interfaces can stay reachable while ufw says deny. Publishing to 127.0.0.1 avoids it. Re-run the outside nmap check after every change.

14. If you think you were exposed

Work in this order. It follows OpenClaw's incident guide, and the steps carry over to Hermes.

1. Contain. Stop the gateway, close the port or go back to loopback, and disable DM and group access while you look.
2. Rotate the gateway token or password, every model API key, chat tokens (for Telegram, /revoke in BotFather), and OAuth grants for connected accounts.
3. Read the gateway logs and session transcripts, check recent config changes, and look for spend you don't recognize. Then run openclaw security audit --deep.
4. Rebuild on a fresh server from a pre-exposure backup if anything looks off. The audit's --fix flag tightens permissions, but it won't rotate secrets or change bind and auth for you.

How we set this up on HostAiHub

Here is what a managed OpenClaw or Hermes instance does:

• Each agent runs in its own isolated container.
• You reach it through our reverse proxy on a private SSL subdomain (name.ai.hostaihub.com). The container's port is mapped to 127.0.0.1 on the host, so it isn't published to the internet.
• Hermes: the dashboard requires a login. Since Hermes' June 2026 hardening it refuses to start a dashboard on anything other than loopback without an auth provider, and we configure that login for every instance.
• OpenClaw: you open it with a tokenized link. The subdomain's origin is allow-listed and device pairing is turned off for this managed setup, which makes the token in that link the key. Treat the link like a password.
• Daily backups kept for 7 days, plus on-demand backups.
• One-click updates with automatic rollback.
• Health checks every few minutes, with automatic restart and incident tracking.

That covers the network exposure behind this year's headlines, plus the backup and update chores. It doesn't decide who can message your bot or which tools it gets, and it can't cap your API key. Items 4 to 8 stay with you on any host, ours included.

OpenClaw and Hermes plans are $10 a month, $100 a year or $250 lifetime (pricing; details for OpenClaw and Hermes). Still choosing? See OpenClaw vs Hermes.