Is OpenClaw Safe? Security Risks and How to Lock It Down in 2026

Yes, if you run the latest stable OpenClaw (v2026.10.5, out October 18) and harden a few defaults. Version 2026.4.15 is the oldest with every critical fix in OpenClaw’s own advisory list, but 81 high-severity fixes came later. The risky parts are by design: tools run on your host without a sandbox or approval prompt, and third-party skills can carry malware.

Most pages that rank for this question were written in February 2026, during the first wave of incidents, and several get the defaults wrong. This guide uses the numbers as of October 18, 2026: OpenClaw’s own advisory log, its current docs and the research published since. For each risk you get the evidence with a link and the exact official setting or command that closes it.

We build Atomic Agent, another local agent, so we have an interest here. We have tried to credit what its team fixed. The short comparison near the end lists where Atomic Agent is weaker too.

Is OpenClaw safe? What the 2026 numbers say

OpenClaw is safe enough for a careful single user on the latest stable version, and risky for anyone who exposes the Gateway, installs skills freely or runs it on a work laptop. The project fixed 722 reported issues in 2026, and its trust model assumes one trusted operator per Gateway. Most incidents came from setups outside that model.

OpenClaw’s security page gives the full picture: 1,799 reports filed since January 2026, 58% closed without an advisory, and 722 fixed and published. Of 137 reports filed as critical, 14 were confirmed critical. The busiest areas were Gateway, auth and scopes (182 advisories), exec, sandbox and approvals (160) and chat connectors (122). As of September 9 the page lists no active bulletins and “no known compromise of OpenClaw infrastructure or of the official install and update channels.”

Most of those advisories came early. Monthly counts were 220 in February, 204 in March and 108 in April, then 67 in May, 45 in June and none in July or August. A batch of 75 followed on September 11, and nothing has been published in October so far. Read the 722 as a project that publishes every fix as an advisory, which means the useful habit is updating often.

The trust model matters for the honest answer. OpenClaw’s docs say it “is not a hostile multi-tenant security boundary for mutually adversarial users sharing one agent or gateway.” Its security policy also treats two things as out of scope: prompt injection that does not bypass a policy, auth, approval, sandbox or tool boundary, and malicious behavior in a plugin a trusted operator installed. If you invite untrusted content or untrusted code in, the defaults will not save you.

7 OpenClaw security risks

These seven risks cover most of the 722 advisories and every major incident of 2026. Two of them (an exposed Gateway and malicious skills) caused most of the real damage. Each section below gives the evidence and the official fix, with setting names exactly as they appear in OpenClaw’s security docs.

1. An exposed Gateway on the internet

What it is. The Gateway is OpenClaw’s control plane, on port 18789 by default. Anyone who can reach it and get past auth controls your agent, and through it your shell, files and chat accounts.

Evidence. Bitsight counted more than 30,000 distinct instances on port 18789 between January 27 and February 8, 2026, and a honeypot study it cites saw probes within minutes, aimed straight at the WebSocket API. SecurityScorecard’s STRIKE team counted 40,214 exposed instances, later 42.9K unique IPs, with 15.2K appearing vulnerable to remote code execution. The problem did not fade: the ACM IMC 2026 poster by Wu et al. found exposure grew 16.3 times in its first measurement period and later stayed above 40,000 live IPs.

Official fix. Keep gateway.bind: "loopback". For remote access, use an SSH tunnel to 127.0.0.1:18789 or Tailscale Serve. The docs say never expose the Gateway unauthenticated on 0.0.0.0, avoid direct public port forwarding, and put an identity-aware proxy in front if it must be public. The exposure runbook covers each case. openclaw security audit flags gateway.bind_no_auth, Tailscale Funnel, short tokens and discovery.mdns.mode="full", which leaks metadata on the local network.

Myth check: “OpenClaw binds to 0.0.0.0 by default.” An r/openclaw comment from March says so, and at least one AI-written guide repeats it. On a host install it is wrong: per the network exposure docs, the Gateway binds to loopback, Gateway auth is required, and onboarding generates a token even for loopback. Container images are different and default to an exposed bind, per the security overview. If you run OpenClaw in Docker, treat it as reachable until you have checked. Bitsight also notes that the old “none” auth mode was removed early on, but older Clawdbot and Moltbot builds that still get deployed can run without auth.

2. Malicious skills from ClawHub

What it is. Skills are instructions plus scripts that your agent follows. A malicious one can tell the agent, or you, to run an installer that steals data.

Evidence. Koi Security’s ClawHavoc report, covered by The Hacker News, found 341 malicious skills out of 2,857 audited, 335 from one campaign that delivered Atomic macOS Stealer through fake “Prerequisites” steps. Koi’s February 16 update raised it to 824 out of more than 10,700. Snyk’s ToxicSkills study of 3,984 skills from ClawHub and skills.sh found a critical issue in 13.4% and 76 confirmed malicious payloads, and its Leaky Skills report found 283 skills that pass API keys through the model’s context. Trend Micro traced 39 skills installing a fake CLI that dropped a new AMOS variant.

What OpenClaw fixed. On February 7 it partnered with VirusTotal: every published skill is hashed and scanned, malicious ones are blocked, suspicious ones stay available with a warning, and all are re-scanned daily. The post itself says a clean scan does not mean a skill is safe. Today the security page says static analysis, VirusTotal and NVIDIA SkillSpector check every skill version before listing, with an open dataset of 67,453 scans. It is still not airtight: Unit 42 found five malicious skills that VirusTotal and ClawScan did not block between February and May, including two macOS infostealers and one that padded its README to 22 MB to evade scanning.

Official fix. Install only what you need and check each skill’s audit status (Pass, Review, Warn, Malicious, Pending or Error). The ClawHub audit docs themselves say a Pass “does not replace your own judgment.” Note one gap: per the tool permissions docs, “OpenClaw does not run built-in local dangerous-code blocking during install/update.” You can add it with security.installPolicy, a local command that returns allow, warn or block for every install, ClawHub included. Pin what may load with plugins.allow, run openclaw security audit --deep after installs, and never follow a skill’s “prerequisite” that pipes base64 into a shell.

3. Prompt injection through chats, email and the web

What it is. Any text the agent reads can contain instructions. If the same agent can also run commands or send messages, that text can steer it.

Evidence. OpenClaw’s prompt injection docs say injection does not need public DMs: “any untrusted content it reads (web search/fetch results, browser pages, emails, docs, attachments, pasted logs/code) can carry adversarial instructions.” The Dutch data protection authority warned in February about hidden commands in websites, emails and instant messages. Three CVEs touched this area: Slack channel metadata reaching the system prompt (CVE-2026-24764), working-directory path injection into prompts (CVE-2026-27001) and ACP resource link injection (CVE-2026-27165).

The defaults. Inbound is reasonably tight: most channels answer unknown DM senders with a pairing code, and groups are allowlisted and usually need a mention. Outbound is loose: agents with the message tool can send across conversations and channel providers by default (tools.message.crossContext.allowAcrossProviders is true), and agent-to-agent messaging is on.

Official fix. Use dmPolicy: "pairing" or a strict allowFrom, groups: { "*": { requireMention: true } } and session.dmScope: "per-channel-peer". Approve new senders explicitly with openclaw pairing approve <channel> <code>. Deny exec, browser, web_fetch and web_search to any agent that reads untrusted content, and give reading and acting to separate agents. Set tools.message.crossContext.allowAcrossProviders: false and allowWithinProvider: false, and tools.agentToAgent.enabled: false. The docs also advise against running these workloads on weak model tiers.

4. Host execution with no sandbox and no approval

What it is. By default, commands the agent decides to run execute directly on your machine, as your user, without asking.

Evidence. This is documented behavior. The sandboxing docs say “Sandboxing is off by default.” The exec approvals docs list exec.security defaulting to full on gateway and node hosts and exec.ask defaulting to off, and the tool permissions docs call that combination “expected behavior, not a bug” under the trusted-operator model. The README still says “Tools run on the host for the main session unless you configure sandboxing.” Microsoft’s Defender team advised treating OpenClaw “as untrusted code execution with persistent credentials” and said it is not appropriate for a standard personal or enterprise workstation.

The sandbox itself has had holes. Two criticals published on March 31 (a TOCTOU race in the remote filesystem bridge and a heartbeat escalation through senderIsOwner) allowed escapes, both fixed in 2026.3.31. A sandbox still raises the bar a lot; just do not treat it as the only layer.

Official fix. Turn the sandbox on for every session:

{ agents: { defaults: { sandbox: { mode: "all", scope: "session", workspaceAccess: "none" } } } }

The docs’ minimal example uses mode: "non-main", which sandboxes every session except the agent’s main one. With the default session.dmScope, your direct chats share that main session, so under non-main your own DMs still run tools on the host. The sandbox also needs a backend: Docker by default (Podman or SSH also work), with no fallback, and you have to build the openclaw-sandbox:trixie-slim image first, per the sandbox setup docs.

For exec, pick one of two policies. To block host exec entirely, use tools.exec.mode: "deny" (the legacy form is security: "deny"). If an agent needs a shell, use tools.exec: { security: "allowlist", ask: "always" } so every command asks. Newer configs use tools.exec.mode, but per the exec approvals docs, pairs with ask: "always" have no exact mode equivalent, so keep both legacy fields in that case. Then disable elevated mode with tools.elevated.enabled: false and keep file tools in the workspace with tools.fs.workspaceOnly: true. If you allowlist interpreters, also set tools.exec.strictInlineEval. Check what is actually in force with openclaw sandbox explain. Microsoft and Thoughtworks both go further and recommend a VM or a dedicated machine.

5. Plaintext credentials that infostealers can grab

What it is. OpenClaw keeps your provider keys, gateway token, device key and chat sessions in files on disk. Malware running as your user can read them.

Where the files are. Per the secrets and storage docs, everything sits under ~/.openclaw/ (or $OPENCLAW_STATE_DIR):

• openclaw.json: gateway and remote tokens, provider settings
• .env: provider API keys
• credentials/: channel sessions such as credentials/whatsapp/<accountId>/creds.json, plus pairing allowlists
• state/openclaw.sqlite: the device keypair, auth tokens and MCP OAuth access and refresh tokens (older builds kept the device key in identity/device.json)
• agents/<agentId>/agent/openclaw-agent.sqlite: model auth profiles and transcripts

Directories are created 700 and files 600. The docs recommend full-disk encryption and make no claim of encryption at rest for these files. Transcripts and tool results keep their original text, credentials included, and file logs default to /tmp/openclaw/.

Evidence. On February 16, Hudson Rock reported an infostealer infection that took OpenClaw files: openclaw.json with the gateway auth token, device.json with a private key, plus soul.md and MEMORY.md. BleepingComputer called it the first reported case of infostealer malware taking OpenClaw secrets. It was a generic file grabber with no OpenClaw-specific module, so any stealer that sweeps home folders can get these files. Hudson Rock also noted that a stolen gateway token can be used to connect remotely if the port is exposed, or to impersonate the client in authenticated requests, which links back to risk 1.

What OpenClaw fixed. A critical (GHSA-8rh7-6779-cjqq) let a .env file in the working directory override host policy; provider keys and any OPENCLAW_* variable are now blocked from untrusted workspace .env files.

Official fix. Keep permissions tight with openclaw security audit --fix or openclaw doctor --fix, turn on full-disk encryption, run OpenClaw under a dedicated OS user and use SecretRefs (openclaw secrets) where you can. If you suspect a compromise, follow the operator incident response order: gateway credentials first, then provider keys. For a wider view of how other agents store keys, see where 13 AI coding agents store your API keys.

6. Gateway token leaks and scope escalation

What it is. The gateway token, and device tokens issued at pairing, decide who can control the agent. Leaking one, or tricking the Gateway into widening one, hands over control.

Evidence. CVE-2026-25253, published February 1 and scored 8.8 by MITRE, let a crafted link make OpenClaw open a WebSocket to an attacker and send its gateway token; the advisory calls it a 1-Click RCE, fixed in 2026.1.29. March brought several criticals in which pairing or device tokens could mint operator.admin and reach remote code execution on nodes, plus a high where revoked tokens kept their live WebSocket sessions (fixed in 2026.3.28). The docs also note that shared-secret HTTP bearer auth “is effectively all-or-nothing operator access.”

What OpenClaw fixed. All of the above, by 2026.3.28.

Official fix. Use a long random gateway.auth.token and never reuse it as hooks.token (the audit flags this, and openclaw doctor --fix rotates it). Review and revoke paired devices with openclaw devices. Rotate gateway.auth.token, gateway.remote.token and then provider keys after any suspected leak. Run separate gateways for separate trust boundaries instead of sharing one.

7. Plugins, npm dependencies and stale versions

What it is. OpenClaw and its plugins pull npm dependencies at install time, and many installs never get updated.

Evidence. The docs state that root and plugin tarballs “ship neither npm-shrinkwrap.json nor package-lock.json,” so dependencies resolve when you install. Criticals in this area included a path traversal in plugin installation (GHSA-qrq5-wjgg-rvqw) and package-manager environment overrides that could redirect installs (GHSA-j7p2-qcwm-94v4); a high (GHSA-3vvq-q2qc-7rmp) showed ClawHub downloads were not integrity-checked until 2026.4.8. Old versions persist: the IMC poster found the January to April version cohorts still made up 69.4% of observed instances on July 1, and Bitsight’s live Groma explorer still shows exposed hosts reporting 2026.3.x and 2026.4.14 (among the few that report a version at all).

Official fix. Update to the latest stable (v2026.10.5) or the extended-stable channel, and keep doing it. Set plugins.allow so only named plugins load. The audit warns about unpinned npm plugin records and plugins with no explicit allowlist. See the dependency locking docs for the rest.

Harden OpenClaw in 10 minutes

Five steps cover most of the risk: update to the latest stable, run the audit, apply the official hardened baseline, turn the sandbox on, and reach the Gateway only through a tunnel. The baseline below comes from OpenClaw’s own hardened baseline page; it suits a messaging assistant and blocks shell, file and automation tools until you allow them back.

Step 1. Update. Install v2026.10.5, the latest stable, using the same method you installed with. Do not stop at 2026.4.15: high-severity fixes kept shipping through September.

Step 2. Run the audit. These are the documented security CLI commands:

openclaw security audit                    # config and filesystem check
openclaw security audit --deep             # adds live Gateway and plugin checks
openclaw security audit --fix              # tightens file perms, open group policy to allowlist
openclaw security audit --json | jq '.summary'
openclaw doctor --fix                      # health checks, perms, rotates a reused hooks.token

Remember that --fix stops at permissions and group policy. The next two steps are on you.

Step 3. Apply the hardened baseline. Generate a token first (for example with openssl rand -hex 32), then merge this into ~/.openclaw/openclaw.json:

{
  gateway: {
    mode: "local",
    bind: "loopback",
    auth: { mode: "token", token: "replace-with-a-long-random-token" },
  },
  session: { dmScope: "per-channel-peer" },
  tools: {
    profile: "messaging",
    deny: ["group:automation", "group:runtime", "group:fs", "sessions_spawn", "sessions_send"],
    fs: { workspaceOnly: true },
    exec: { security: "deny", ask: "always" },
    elevated: { enabled: false },
    sessions: { visibility: "agent" },
    agentToAgent: { enabled: false },
  },
  channels: {
    whatsapp: { dmPolicy: "pairing", groups: { "*": { requireMention: true } } },
  },
}

Swap whatsapp for the channels you use. To stop the agent from posting across chats, also set tools.message.crossContext.allowAcrossProviders: false and tools.message.crossContext.allowWithinProvider: false.

Step 4. Turn on the sandbox and check it.

# after setting agents.defaults.sandbox.mode to "all" and building the image (see risk 4)
openclaw sandbox explain                   # shows effective sandbox mode and tool policy
openclaw status --all                      # pasteable diagnostics, secrets redacted

Step 5. Reach it remotely without exposing it. Use an SSH tunnel such as ssh -N -L 18789:127.0.0.1:18789 you@your-server, or Tailscale Serve. Do not forward port 18789 on your router.

If you need shell access back for coding work, allow it agent by agent with security: "allowlist", ask: "always", and keep that agent away from untrusted inboxes and web content.

Incident timeline 2026

OpenClaw’s bad stretch ran from late January to early April 2026: a 1-click RCE, a poisoned skill marketplace, tens of thousands of exposed gateways and the first infostealer theft, followed by a wave of critical fixes. Since April the record is quieter, with one large advisory batch on September 11.

• Jan 28: Cisco calls personal agents like OpenClaw a “security nightmare” after testing a skill that behaved like malware.
• Feb 1: CVE-2026-25253 published (fixed in 2026.1.29). Koi discloses ClawHavoc the same day.
• Feb 5: Snyk publishes ToxicSkills and Leaky Skills.
• Feb 7: OpenClaw announces VirusTotal scanning for ClawHub.
• Feb 9: Bitsight and SecurityScorecard publish exposure counts.
• Feb 12: The Dutch data protection authority warns against use on systems with sensitive data.
• Feb 16: Hudson Rock reports an infostealer taking OpenClaw config files, the first such case per BleepingComputer.
• Feb 19-20: Microsoft Defender publishes isolation guidance; Thoughtworks restricts OpenClaw on its managed systems.
• Mar 12-31: Most of the 14 critical advisories land, covering scope escalation to operator.admin and sandbox escapes.
• Apr 15: Thoughtworks Radar places OpenClaw on Caution.
• Apr 16: The last critical advisory in OpenClaw’s own list is published, fixed in 2026.4.15.
• Jun 1: OpenClaw announces NVIDIA skill screening for ClawHub.
• Jun 23: Unit 42 reports five malicious skills that VirusTotal and ClawScan did not block.
• Jul 2: GitHub’s advisory database publishes GHSA-w4v6-g3wm-w36c, rated critical there and fixed in 2026.4.29.
• Sep 11: A batch of 75 advisories is published.
• Oct 12: The ACM IMC poster reports exposure that stayed above 40,000 live IPs.
• Oct 18: v2026.10.5 released.

When to pick something else

Pick something else if you cannot isolate OpenClaw on a VM or a spare machine, if you want approval prompts without writing config, or if your employer restricts it, as Thoughtworks does. If you mostly need Telegram or Discord plus approvals, a smaller agent can be easier to keep safe. For a full field review, see our OpenClaw alternatives guide, and for the two-way pick, our Hermes vs OpenClaw comparison. If you want the model off the cloud too, start with what a local AI agent is.

Disclosure: we build Atomic Agent, so weigh this section with that in mind. Compared row by row on default settings, Atomic Agent is ahead on execution (it asks before gated actions), behind on remote access (its local API has no auth unless you pass a key, while OpenClaw’s Gateway requires one) and roughly level on the other five. Neither sandboxes commands by default; OpenClaw offers an opt-in sandbox and Atomic Agent has none. Telemetry is a separate point: Atomic Agent’s is on by default, while OpenClaw’s feature stats are opt-in. Claims about it are checked against its code at v0.6.9 and Desktop v0.0.3, released October 15, 2026.

Two caveats in OpenClaw’s favor. Its opt-in sandbox is a real advantage, and Atomic Agent has nothing equivalent: approvals decide whether a command runs, but once approved it runs on your host. OpenClaw’s telemetry default is also stricter. Atomic Agent’s 0600 key files share the same infostealer exposure as OpenClaw’s, its traces store tool output as is, and its outbound HTTP tool does not ask by default. Neither tool replaces running on a machine you can afford to lose. If approvals by default fit how you work, download Atomic Agent and try it next to a hardened OpenClaw.

Frequently asked questions

Verdict: is OpenClaw safe enough for you?

Yes for a single technical user who runs the latest stable (v2026.10.5), keeps the Gateway on loopback, applies the hardened baseline, sandboxes all sessions and vets every skill. No for a shared or work machine, an exposed container, or anyone who will install skills on trust.

The team fixed every critical in its own 2026 list; the remaining risk lives in the defaults and in what you connect. Run openclaw security audit --deep today, read what it flags and fix it. Then decide whether shell access belongs on that machine at all.

Advisory counts come from OpenClaw’s GitHub security advisories and openclaw.ai/security, checked in October 2026. Versions and star counts come from the GitHub API at the same time. Atomic Agent claims were checked against its source code at v0.6.9 and Desktop v0.0.3 (October 15, 2026). We did not test OpenClaw’s hardening ourselves; the settings above are quoted from its documentation.