security

OpenClaw Security Hardening

Threat Landscape

OpenClaw instances face real, documented threats. A Cisco/Shodan scan discovered over 135,000 exposed instances on the public internet, many running without authentication. CVE-2026-25253 is a critical remote-code-execution vulnerability that affects older versions. The community skill ecosystem (3,200+ published skills) has been shown to harbor supply-chain risks: a researcher demonstrated a malicious skill ("What Would Elon Do?") that performed data exfiltration, prompt injection, and command injection in a single package. OpenClaw's own documentation states there is "no perfectly secure setup" -- security is configurable, not foundational. Treat every configuration choice as a deliberate security decision.

Four-Layer Defense Model

Apply security in depth across four layers. Every layer is independently valuable; all four together provide strong protection.

Layer 1 -- Network Isolation

The gateway binds to localhost ("loopback") by default. This is the single most important security property: it prevents all remote network access to the gateway port. Never change the bind address without also enabling gateway authentication.

Gateway bind options in openclaw.json:

Value	Scope	When to use
"loopback"	localhost only (default)	Single-user local installs
"lan"	Local network interfaces	Trusted home/office LAN with auth
"tailnet"	Tailscale VPN interface	Remote access via Tailscale
"custom"	Specific IP or interface	Advanced deployments with auth

For any bind value other than "loopback", always require gateway authentication (Layer 2). Refer to ${CLAUDE_PLUGIN_ROOT}/skills/security/references/network-security.md for firewall rules, Tailscale Serve configuration, reverse proxy templates (nginx, Caddy), and the Ansible 4-layer defense model (firewall + VPN + container isolation + systemd hardening).

Layer 2 -- Gateway Authentication

Configure the gateway.auth block in openclaw.json. Three modes are available:

Token authentication (recommended)

Generate a cryptographically random token:

openclaw doctor --generate-gateway-token

Store the resulting value as the OPENCLAW_GATEWAY_TOKEN environment variable. Set the auth mode in config:

{
  gateway: {
    auth: {
      mode: "token"
      // Token read from OPENCLAW_GATEWAY_TOKEN at runtime
    }
  }
}

Never hardcode the token in the config file. Use "${OPENCLAW_GATEWAY_TOKEN}" environment variable interpolation.

Password authentication

Less secure than token mode but acceptable for convenience on a loopback bind:

{
  gateway: {
    auth: {
      mode: "password",
      password: "${OPENCLAW_GATEWAY_PASSWORD}"
    }
  }
}

Trusted-proxy authentication

For deployments behind a reverse proxy (nginx, Caddy) that handles authentication upstream:

{
  gateway: {
    auth: {
      mode: "trusted-proxy",
      trustedProxyHeader: "X-Forwarded-User"
    }
  }
}

Full configuration details and per-mode options are in ${CLAUDE_PLUGIN_ROOT}/skills/security/references/gateway-auth.md.

Layer 3 -- Channel Access Control

Control who can interact with the bot through direct messages and group channels.

DM policy (dmPolicy in openclaw.json):

Policy	Behavior
"pairing"	Default. Users must enter a one-time code to pair. Codes expire after 1 hour.
"allowlist"	Only platform-specific peer IDs in the allowFrom array may interact.
"open"	Any user on the platform can DM the bot. Avoid in production.
"disabled"	DMs are turned off entirely.

Use "pairing" or "allowlist" for production. The allowFrom field accepts arrays of platform-specific peer IDs to restrict access on a per-channel basis.

Tool restrictions:

• Define toolAllowlist to permit only specific tools per channel.
• Define toolBlocklist to deny dangerous tools while allowing all others.
• Use the /elevated command within a session to temporarily grant host-level tool access when needed, rather than permanently broadening permissions.

See ${CLAUDE_PLUGIN_ROOT}/skills/security/references/access-control.md for policy examples, allowlist ID formats per platform, and tool restriction patterns.

Layer 4 -- Docker Sandboxing

Run tool-executing sessions inside Docker containers to limit blast radius from malicious or runaway tool calls.

Sandboxing modes (sandbox.mode in openclaw.json):

Mode	Containers	Use case
"off"	None	Single trusted user, local only
"non-main"	Group chats and non-primary DMs	Recommended for multi-user setups
"all"	Every session	Maximum isolation

Container scope (sandbox.scope):

Scope	Isolation level
"session"	One container per conversation session (most isolated)
"agent"	One container per agent identity
"shared"	Single container for all sandboxed sessions

Workspace access (sandbox.workspaceAccess):

Access	Behavior
"none"	No host filesystem access
"ro"	Read-only mount of workspace
"rw"	Read-write mount of workspace

The sandbox engine blocks bind-mounting sensitive host paths by default: Docker socket (/var/run/docker.sock), /etc, /proc, /sys, and /dev. These cannot be overridden from config.

Refer to ${CLAUDE_PLUGIN_ROOT}/skills/security/references/sandboxing.md for Docker prerequisites, custom image configuration, resource limits, and scope trade-offs.

CVE and Supply-Chain Awareness

CVE-2026-25253 -- Critical RCE

A critical remote-code-execution vulnerability was assigned CVE-2026-25253. Verify the installed version and update immediately if running an affected release:

openclaw --version
npm update -g @anthropic/openclaw

After updating, run openclaw doctor to confirm the fix is in place.

Community Skill Supply-Chain Risk

The 3,200+ community-published skills present a real attack surface. A demonstrated attack ("What Would Elon Do?") combined three vectors in one skill:

1. Data exfiltration -- reading and transmitting host files.
2. Prompt injection -- overriding system instructions.
3. Command injection -- executing arbitrary shell commands via tool calls.

Mitigate supply-chain risk:

• Audit skills before installation using the Cisco Skill Scanner: github.com/cisco-ai-defense/skill-scanner
• Prefer skills from verified publishers.
• Enable Docker sandboxing (Layer 4) so compromised skills cannot escape the container.
• Review skill source code; skills are plain-text Markdown and are human-readable.

Enterprises should also account for Shadow AI risk -- employees installing unvetted OpenClaw instances with unaudited skills on corporate networks.

Full CVE details and scanner usage are in ${CLAUDE_PLUGIN_ROOT}/skills/security/references/cve-awareness.md.

Security Hardening Checklist

Apply these practices to every OpenClaw deployment:

1. Keep gateway on loopback. Only change the bind address when remote access is genuinely required.
2. Use Tailscale for remote access. Tailscale Serve exposes the gateway over an encrypted mesh VPN without opening firewall ports.
3. Enable gateway auth token for non-loopback binds. Generate with openclaw doctor --generate-gateway-token and store as an environment variable.
4. Run openclaw doctor regularly. It detects misconfigurations, missing auth on exposed binds, outdated versions, and known CVEs.
5. Use Docker sandboxing for group chats. Set sandbox.mode to "non-main" or "all" when untrusted users can trigger tool calls.
6. Review skills with Cisco Skill Scanner. Scan every community skill before installation.
7. Run as a non-root user. Never run the OpenClaw process as root. Use a dedicated service account.
8. Update frequently. Subscribe to release notifications and apply updates promptly to stay ahead of disclosed vulnerabilities.

Verification

After applying hardening changes, verify the security posture:

# Health check -- reports auth, bind, version, and CVE status
openclaw doctor

# Gateway status -- confirms bind address and auth mode
openclaw gateway status

# Test that unauthenticated requests are rejected (non-loopback)
curl -s -o /dev/null -w "%{http_code}" http://<bind-address>:18789/
# Expect 401 or 403

Reference Files

For detailed configuration, examples, and platform-specific guidance, consult:

• ${CLAUDE_PLUGIN_ROOT}/skills/security/references/gateway-auth.md -- Auth mode configuration, token generation, proxy headers.
• ${CLAUDE_PLUGIN_ROOT}/skills/security/references/sandboxing.md -- Docker setup, scope trade-offs, resource limits, blocked paths.
• ${CLAUDE_PLUGIN_ROOT}/skills/security/references/access-control.md -- DM policies, allowlist formats, tool restrictions, /elevated usage.
• ${CLAUDE_PLUGIN_ROOT}/skills/security/references/network-security.md -- Tailscale Serve, UFW rules, reverse proxy configs, Ansible playbook.
• ${CLAUDE_PLUGIN_ROOT}/skills/security/references/cve-awareness.md -- CVE-2026-25253 details, Cisco Skill Scanner, supply-chain defenses.