TL;DR

  • The main risk is an exposed gateway. If it listens on anything other than 127.0.0.1 and has no token, whoever finds it gets remote code execution on your machine. More than forty thousand installs were found exposed that way in February 2026.
  • Three things worth checking today: what interface your gateway listens on, whether it has a token, and whether your version is older than 2026.1.29 (the release that fixed ClawBleed).
  • One command checks all three. Download it and run it:
curl -sO https://raw.githubusercontent.com/cain66666/openclaw-hardening-check/main/openclaw-hardening-check.mjs
node openclaw-hardening-check.mjs

One Node file, no dependencies. It downloads as a separate step, so read it first if you want to.

  • It only reads. Fixes nothing, sends nothing anywhere, never prints your secrets. Whatever it finds, you fix. How, below.

I'm not a security researcher. I run OpenClaw and Hermes in production and I usually learn about a problem when it wakes me up. Almost everything here is something I got wrong myself, collected into the list I run against the machines I'm responsible for. It isn't an audit and it isn't a guarantee. A green result means the checks below passed. Nothing more.

What actually threatens a self-hosted OpenClaw

Let's skip the abstractions. In January 2026, OpenClaw got hit with CVE-2026-25253, nicknamed "ClawBleed," CVSS 8.8. The mechanism is simple, which is what makes it ugly: the Control UI blindly trusted a gatewayUrl query parameter and connected to it automatically, handing your gateway auth token to whoever handed you the link. Open one crafted page and your token was gone, and with it, control of your agent.

By early February, security teams scanning the internet were reporting more than forty thousand exposed instances, most of them vulnerable, and over twelve thousand exploitable to RCE. Separately, security researchers found more than eight hundred malicious skills in ClawHub, the skill marketplace, as the registry grew through early 2026. It was fixed in 2026.1.29.

The CVE details above (severity, the fix version, the mechanism) are from NVD; the exposure counts come from security teams who scanned the internet, and they vary by who scanned and when. These are the lower, well-corroborated figures, not the inflated ones that spread first. The point holds either way: an autonomous agent with access to your email, files, and subscriptions, sitting exposed on the internet, is the target people go looking for. Here's what to do about it, point by point.

Is your gateway exposed to the internet?

This is the most important item, so it's first. Your OpenClaw gateway should listen on loopback (127.0.0.1), not 0.0.0.0 or an external interface. If it listens outward and has no token, anyone who finds your IP and port controls your agent.

There's a trap here that's easy to walk into without noticing: the default is different inside a container. If you run OpenClaw in Docker, Podman, or Kubernetes with Tailscale off, the default bind mode becomes auto, and that resolves to 0.0.0.0, because loopback inside a container is unreachable from the host. So you changed nothing, left the default "as the docs show," and your gateway is open. On bare metal the default is safe; in a container it isn't, and most "spin it up in 30 minutes" guides say nothing about it.

Check the reality, not just the config. The config can say loopback while a command-line flag or a systemd unit overrides it at runtime. Look at what the gateway process is actually listening on. On Linux that's visible in its open sockets. The config is intent; the socket is fact.

Auth: where the token actually lives

Your gateway token should exist, be long, and not be a default placeholder. That's the obvious part. The non-obvious part cost me an evening.

On 2026.6.x, the gateway service resolves the auth token config-first: it reads gateway.auth.token in ~/.openclaw/openclaw.json, and an OPENCLAW_GATEWAY_TOKEN you assumed was authoritative can quietly lose to it (direct local clients still prefer the env token; the managed gateway service prefers the config). After an update my gateway came up, the bot answered, everything looked alive, but the control panel said "gateway offline" and the logs showed token_mismatch. I dutifully chased the environment: checked the variable was set, that it matched, restarted. None of it helped, because the gateway was comparing the presented token against the one in the config, and the config didn't have one; the update had scrubbed it, assuming the old "read from env" behavior.

The lesson isn't "here's an OpenClaw bug." It's broader: "the token is set" and "the gateway can see the token" are two different claims. Before you call a gateway protected, find out where your version reads the token from, and confirm it's there. And if you have a string like secretref-env:NAME or $VAR, that's a reference to an environment variable, not the secret itself; if the variable isn't set, you effectively have no token, and on a token-mode gateway it won't start.

Version and the pin

Don't run latest blind. I get the appeal: set openclaw@latest once and it's always fresh. That's how I earned a multi-day cleanup.

An unpinned latest pulled in a new minor version one morning, and the contracts had changed underneath it: schedules moved out of files into SQLite, the config shape was different, settings that used to be accepted started getting rejected. None of it was flagged as breaking; the install on a fresh machine just stopped coming up, and I spent days working out what had shifted.

There are two risks here, and the second is worse. The first is someone else's regression: a fresh version broke something and you find out in production. The second is the supply chain: if a release is ever compromised, latest pulls it straight into an autonomous agent that has access to your data and permission to act. Pinning isn't about falling behind. It's about making the upgrade your decision, made when you're ready for it, instead of a surprise from npm install.

How I do it: the version is fixed to a specific number, a new one gets validated before I let it roll out, and only then does the pin move forward. You still get the security fixes; you just don't get someone's regression bundled in with them. And while you're at it, confirm your current version isn't older than 2026.1.29, or you're still exposed to the ClawBleed issue above.

Third-party skills and plugins

Eight hundred-plus malicious skills in ClawHub isn't an abstract statistic. A skill is code that runs inside your agent, with its permissions and its access. Installing a third-party skill means letting someone else's code into a system that reaches into your email and files.

The practice is simple: know what you have installed, and separate bundled from third-party. Bundled plugins ship with the product and you can trust them about as far as you trust OpenClaw itself. Anything you pulled from the marketplace is a separate trust decision, and it's worth making it on purpose, not "installed it to try it and forgot."

"Configured" is not "applied"

Short item, but it matters, because it can turn all the previous ones into a false sense of safety. You can change a security setting, the file writes correctly, and the change never reaches the running agent.

That happened to me: I changed an active setting, the config file updated correctly, status showed the new value, and the bot kept running on the old one. Turned out the gateway's config watcher had died: the system was full and it had run out of the kernel's inotify watcher limit. The watcher died silently, hot-reload stopped firing, and every config change looked applied while it wasn't. The fix was restarting the gateway, which rebuilds its state from the file.

The takeaway: after you change something that affects security, verify against the live runtime, not against the fact that the file saved. "Written" and "in effect" are, again, two different claims, and the gap between them is the window where you think you're protected and aren't.

Check all of this in one command

I pulled these checks into a small tool: openclaw-hardening-check. It's a single Node file with zero dependencies. It reads your config and tells you what's wrong: what interface the gateway listens on, whether there's a token and whether it's weak, whether your version predates the ClawBleed fix, which of your plugins aren't bundled, and the file modes on your secrets.

What it doesn't do matters just as much. It fixes nothing; it only reads. It makes no network calls: no telemetry, no online checks, nothing. And it never prints a secret's value, only present/absent, source, and length, specifically so you can safely paste its output into a GitHub issue. Where it can't honestly determine something, it says "cannot check" rather than inventing a result. That's deliberate: a security tool that lies "all good" is worse than no tool at all.

And it downloads as a file you can read before you run it. A security tool that asks you to pipe it straight into a shell hasn't earned your trust.

What this checklist can't do

I'll say it plainly, because honesty is the trust here. This is not a pentest and not an audit. It's a handful of things I got burned by in production, not an exhaustive threat model. It checks configuration, not your network perimeter, not what your skills actually do, not who you've handed machine access to. A green result does not mean you're safe; it means these specific checks passed.

If you're running anything serious on this agent (sensitive data, money, client access), you want a real security professional and a real review, not a checklist from an operator. I'm not saying that to cover myself. I'm saying it because seeing the edges of your own tool is part of what makes it usable.

If you'd rather not do this yourself

All of the above is work, and it doesn't end: OpenClaw ships updates, contracts change, and every update means checking again that nothing shifted. That's what I do. If holding and hardening this stack yourself isn't what you want, Cain runs both OpenClaw and Hermes together, pinned to a version that gets validated before it's allowed to roll out, on a dedicated server provisioned for you, one client per server. Security fixes reach you; other people's regressions don't. That's one option, not the one right answer. If you're happy running it all yourself, the checklist and the tool above are where I'd start.

FAQ

Is OpenClaw safe to self-host? Yes, if you configure it. OpenClaw gives you full control and full responsibility: the defaults aren't always safe (especially in a container), and behavior changes between versions. Work through the items above, starting with whether your gateway is exposed.

Is my gateway exposed to the internet? Check what interface it actually listens on, not just what the config says. It should be 127.0.0.1. In a container the default resolves to 0.0.0.0; you have to close that explicitly.

What is ClawBleed and am I affected? CVE-2026-25253: a gateway auth-token leak through a trusted gatewayUrl parameter, CVSS 8.8, fixed in 2026.1.29. If your version is older, you're exposed; update.

Where does OpenClaw read the gateway token from? On 2026.6.x the gateway service resolves it config-first (gateway.auth.token), so an environment token can lose to the config. Confirm the token is where your version actually reads it from.

Should I pin my version or run latest? Pin it. latest will eventually pull a breaking or compromised version into an autonomous agent with access to your data. Update on purpose.

Are ClawHub skills safe? A third-party skill is someone else's code in your agent. The marketplace has had eight hundred-plus malicious ones. Install deliberately, and know what you have.

How do I check my OpenClaw is secure? Work through the checklist above, or run openclaw-hardening-check. It verifies these points and won't break or transmit anything doing it.

Ilya Prudnikov runs private OpenClaw and Hermes deployments. The tool in this article is that checklist, extracted into code and made safe to publish. The author is not a security professional; this is an operator's checklist, and the tool's README is just as blunt about its limits.