OpenClaw Security Hardening Guide 2026

Why OpenClaw Security Deserves Serious Attention

OpenClaw is a personal AI assistant with direct access to your messages, files, calendars, APIs, and shell. A misconfigured deployment is not an inconvenience — it is an open door. The v2026.2.21 release shipped a critical security fix (GHSA-76m6-pj3w-v7mf: SHA-1 to SHA-256 migration for gateway locks and tool-call IDs) alongside patches for two Node.js CVEs affecting runtimes older than v22.12.0. Before you expose any OpenClaw deployment to a real channel or real users, this guide walks through every layer of security configuration.

Runtime: Upgrade to Node.js 22.12.0 or Later

OpenClaw's security requirements changed in v2026.2.21 — Node.js 22.12.0 minimum is now enforced. Earlier Node.js versions are vulnerable to CVE-2025-59466 and CVE-2026-21636, both patched in the 22.12 LTS series. Running OpenClaw on older runtimes is explicitly unsupported and unpatched.

# Check your current version
node --version

# Use nvm to install the latest LTS
nvm install 22
nvm use 22

If you are running OpenClaw via Docker, update your base image tag. Do not pin to node:22 (floating tag) in production — pin to a specific SHA-256 digest or a patch version like node:22.12.0-bookworm-slim so you know exactly what you're running.

The SHA-256 Fix (GHSA-76m6-pj3w-v7mf)

Prior to v2026.2.21, OpenClaw used SHA-1 hashes for gateway session locks and synthetic tool-call IDs. SHA-1 is cryptographically broken — collision attacks are practical. The fix upgrades all internal hashing to SHA-256. If you are running any version older than v2026.2.21, update immediately.

After updating, restart your OpenClaw process — the new hashing takes effect on the next gateway start. No config changes are required; the fix is internal to the runtime.

Gateway Authentication

The OpenClaw gateway is your AI assistant's control plane. By default it binds only to loopback (127.0.0.1 / ::1) — never expose it directly to the public internet. Configure two authentication layers:

# In your .env or environment
OPENCLAW_GATEWAY_TOKEN=<long-random-string-minimum-32-chars>
OPENCLAW_GATEWAY_PASSWORD=<strong-password-for-web-UI>

Generate the token with a cryptographic random generator — not a password manager's weak random:

node -e "console.log(require('crypto').randomBytes(48).toString('hex'))"

Never share your gateway token in chat, commits, or bug reports. Rotate it immediately if you suspect it has been exposed.

The v2026.2.21 release also decoupled the ownerDisplaySecret HMAC from the gateway token — configure it separately in openclaw.json to further limit the blast radius of any individual secret exposure.

DM Policy: Lock Down Who Can Talk to Your Agent

OpenClaw's default DM policy is pairing — unknown senders receive a pairing code and their messages are not processed until they pair. This is the correct default for most deployments. Never switch to open without also configuring an allowFrom allowlist:

{
  "auth": {
    "dmPolicy": "pairing",
    "allowFrom": [
      "+44123456789",
      "your-telegram-username",
      "your-discord-user-id"
    ]
  }
}

For group channel deployments (Discord servers, Slack workspaces), review the allowFrom list and groupPolicy settings carefully. A group with dmPolicy="open" and no allowlist will process messages from anyone who can reach the channel — including strangers if the channel is public.

Filesystem Sandboxing

By default, OpenClaw's file tools (read_file, write_file, edit_file) can access any path on disk that the process user can read or write. In production, lock this down:

{
  "tools": {
    "fs": {
      "workspaceOnly": true
    },
    "exec": {
      "applyPatch": {
        "workspaceOnly": true
      }
    }
  }
}

With workspaceOnly: true, the agent can only read and write within your designated workspace directory. This is critical if your agent has access to a shell or code execution skills — without this restriction, prompt injection attacks can instruct the agent to read ~/.ssh/id_rsa or write to system directories.

Docker Hardening

Running OpenClaw in Docker gives you strong isolation, but only if you configure it correctly. The official Docker image runs as a non-root node user — do not override this with --user root. Apply additional hardening flags:

docker run   --read-only   --cap-drop=ALL   --cap-add=NET_BIND_SERVICE   --security-opt=no-new-privileges   --tmpfs /tmp:rw,noexec,nosuid   ghcr.io/openclaw/openclaw:latest

• --read-only: Makes the container filesystem immutable; only explicitly mounted volumes can be written
• --cap-drop=ALL: Drops all Linux capabilities (root privileges are dropped even for the root user)
• --cap-add=NET_BIND_SERVICE: Re-adds only what is needed to bind ports
• --security-opt=no-new-privileges: Prevents privilege escalation via setuid binaries

Pin your Docker image to a specific SHA-256 digest rather than a version tag, since tags are mutable:

ghcr.io/openclaw/openclaw@sha256:<digest>

Exec Approval Flows

If you enable shell execution or code-running skills, configure an approval flow so the agent cannot execute shell commands without explicit human confirmation. In openclaw.json:

{
  "tools": {
    "exec": {
      "requireApproval": true,
      "approvalTimeout": 60
    }
  }
}

This causes the agent to send a confirmation request to you before running any shell command, displaying the exact command it intends to execute. You approve or reject via a reply. Without this, a prompt injection attack embedded in a webpage, email, or file could instruct the agent to run arbitrary commands on your behalf.

SSRF and Network Guards

Skills that make outbound HTTP requests (browser, fetch, healthcheck, API integrations) should be restricted to known-safe destinations. Configure an SSRF allowlist to prevent the agent from making requests to internal network addresses on your behalf:

{
  "tools": {
    "fetch": {
      "allowedHosts": ["api.openai.com", "api.anthropic.com", "api.telegram.org"],
      "blockPrivateRanges": true
    }
  }
}

blockPrivateRanges: true prevents requests to 10.x.x.x, 192.168.x.x, 172.16-31.x.x, and 127.x.x.x — the ranges attackers target in SSRF attacks against internal services.

Plugin and Skill Trust

OpenClaw loads plugins (extensions) and skills in-process — they are not sandboxed from the main process. A malicious skill or plugin has full access to your environment variables, API keys, and filesystem (within the process permissions). Only install skills and plugins from sources you trust:

• Bundled skills — reviewed by the OpenClaw core team
• ClawHub skills — community-reviewed, but inspect the SKILL.md before installing
• Workspace skills — your own code, fully under your control
• Third-party npm packages loaded as plugins — treat with the same scrutiny as any npm install

The OpenClaw threat model explicitly states: "Anyone who can modify ~/.openclaw is effectively a trusted operator." Protect that directory accordingly.

Security Monitoring and Updates

Subscribe to the OpenClaw GitHub Security Advisories to receive notifications when new CVEs are published. The project's Security & Trust Officer (Jamieson O'Reilly, founder of Dvuln) reviews and responds to responsible disclosures — report vulnerabilities to security@openclaw.ai.

For self-hosted deployments, set a reminder to check for updates weekly. The v2026.2.21 release shipped a critical patch with no advance warning — production deployments that lag on updates carry real risk.

The Security Complexity Reality

A properly hardened OpenClaw deployment requires correct configuration across eight distinct security layers: runtime version, gateway authentication, DM policy and allowlists, filesystem sandboxing, Docker hardening, exec approval flows, SSRF guards, and plugin trust management. Getting all eight right on a first deployment is challenging — and mistakes in any one of them can undermine the others.