OpenClaw Security Guide

OpenClaw's Threat Model: What Can Go Wrong

The main risks fall into several connected layers:

• Untrusted input: messages, webpages, email, documents, and tool output can contain instructions the model should not follow.
• Credential exposure: channel tokens, model keys, browser sessions, and local SecretRefs can unlock other systems.
• Excessive authority: host shell, filesystem, browser, or messaging tools can turn a mistaken decision into an external action.
• Shared context: if several users share one DM session, one person's private context can leak into another conversation.
• Network exposure: a Gateway reachable from the public internet faces authentication, origin, proxy, and brute-force risks.
• Supply chain: plugins and Skills can execute code with the permissions of their runtime.

Security controls must reduce both the probability of a bad instruction being accepted and the damage available after it is accepted.

CVE-2026-25253: WebSocket Handshake RCE — Severity and Patch Status

CVE-2026-25253 was a high-severity one-click remote-code-execution chain. The Control UI trusted a gatewayUrl query parameter, connected to an attacker-controlled WebSocket endpoint, and exposed the stored Gateway token. The stolen token could then be used to change configuration and invoke privileged actions.

The GitHub-reviewed advisory lists clawdbot versions through 2026.1.28 as affected and 2026.1.29 as patched. If an installation predates that version, upgrade before using it. A modern build should still be treated as security-sensitive: this patch addresses one flaw, not prompt injection, overbroad permissions, or unsafe third-party code.

Check the active installation and release channel with:

openclaw --version
openclaw update status --json
openclaw doctor

Authentication: Why dangerouslyDisableDeviceAuth Is Exactly That

gateway.controlUi.dangerouslyDisableDeviceAuth disables Control UI device identity checks. OpenClaw's audit catalog marks this as critical. It is a break-glass debugging switch, not a convenient production setting.

Use Gateway token or password authentication, keep device identity enabled, and serve the Control UI through localhost or HTTPS. allowInsecureAuth is also a compatibility setting with narrow local behavior; it should not be described as a replacement for real authentication.

For a shared-secret configuration, store a long random token outside version control:

{
 gateway: {
 bind: "loopback",
 auth: {
 mode: "token",
 token: "REPLACE_WITH_A_LONG_RANDOM_TOKEN"
 }
 }
}

Network Exposure: Never Bind OpenClaw to 0.0.0.0 Without a Firewall

The current Gateway uses named bind modes such as loopback, lan, tailnet, or custom; a custom bind may fall back to 0.0.0.0 when its address is unavailable. Any non-loopback exposure needs authentication and an explicit understanding of who can reach the port.

Prefer loopback plus an SSH tunnel or a private Tailscale path. If a reverse proxy is required, configure trusted proxies, allowed browser origins, HTTPS, and rate limits. Do not assume a cloud firewall alone protects a token that can be stolen through a browser or logged by a careless deployment.

Malicious Skills: ClawHub Skill Vetting and What to Trust

OpenClaw's own documentation says plugins run in-process and should be treated as trusted code. Skill folders can also influence agent behavior and invoke local tools. The platform does not promise that a popular ClawHub listing is safe.

Before installation, inspect the source, pin an exact version when practical, check scripts and dependency changes, and grant only the tools and directories the Skill needs. Use plugins.allow for an explicit plugin allowlist and run openclaw security audit --deep for code-safety findings. Do not treat stars, downloads, or publisher labels as a security guarantee.

Securing VPS-Hosted OpenClaw With Cloudflare Tunnel

A Cloudflare Tunnel can remove the need for a public inbound Gateway port, but the tunnel is only one layer. Keep OpenClaw bound to loopback, require Gateway authentication behind the tunnel, protect the hostname with an access policy, and set gateway.controlUi.allowedOrigins to the exact HTTPS origin.

Cloudflare Tunnel is not the only supported pattern, and OpenClaw's official minimum baseline emphasizes loopback plus token authentication, isolated DM sessions, sandboxing for non-main work, and restrictive tool policy. Apply those controls regardless of the tunnel vendor.

Security Hardening Checklist (10 Items)

1. Upgrade to a supported release and confirm CVE-2026-25253 is patched.
2. Run openclaw doctor, openclaw security audit, and the deep audit.
3. Keep gateway.bind on loopback unless remote exposure is intentional.
4. Require a long Gateway token or password and rotate leaked credentials.
5. Leave device authentication enabled and remove dangerous compatibility flags.
6. Set explicit DM, group, user, role, and channel allowlists.
7. Use session.dmScope: "per-channel-peer" when more than one person can send DMs.
8. Sandbox non-main sessions and deny shell, browser, elevated, or destructive tools unless required.
9. Review and pin plugins and Skills; protect the state, config, credential, and session directories.
10. Back up configuration, document accepted warnings, and retest after every major update.

Use the OpenClaw Telegram guide or Discord and Slack guide to apply these controls at the channel layer.

In Verdent

Verdent is a separate AI development environment, not a security layer for OpenClaw. If a workflow involves modifying a codebase, keep repository work in a controlled development process with review and verification, while applying OpenClaw's own security controls to the messaging and Gateway side.

Sources: OpenClaw security guide, security audit checks, exposure runbook, and GitHub advisory GHSA-g8p2-7wf7-98mq.