security
Guides users through OpenClaw security hardening, gateway authentication, Docker sandboxing, access control policies, network security, and CVE awareness. Activates when the user mentions "security", "hardening", "gateway auth", "sandbox", "access control", "firewall", "CVE", "vulnerability", "exposed", "pairing code", "DM policy", "Tailscale", "reverse proxy", or "skill scanner".
From openclaw-assistnpx claudepluginhub jamesprial/prial-plugins --plugin openclaw-assistThis skill uses the workspace's default tool permissions.
references/access-control.mdreferences/cve-awareness.mdreferences/gateway-auth.mdreferences/network-security.mdreferences/sandboxing.mdOpenClaw 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
toolAllowlistto permit only specific tools per channel. - Define
toolBlocklistto deny dangerous tools while allowing all others. - Use the
/elevatedcommand 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:
- Data exfiltration -- reading and transmitting host files.
- Prompt injection -- overriding system instructions.
- 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:
- Keep gateway on loopback. Only change the bind address when remote access is genuinely required.
- Use Tailscale for remote access. Tailscale Serve exposes the gateway over an encrypted mesh VPN without opening firewall ports.
- Enable gateway auth token for non-loopback binds. Generate with
openclaw doctor --generate-gateway-tokenand store as an environment variable. - Run
openclaw doctorregularly. It detects misconfigurations, missing auth on exposed binds, outdated versions, and known CVEs. - Use Docker sandboxing for group chats. Set
sandbox.modeto"non-main"or"all"when untrusted users can trigger tool calls. - Review skills with Cisco Skill Scanner. Scan every community skill before installation.
- Run as a non-root user. Never run the OpenClaw process as root. Use a dedicated service account.
- 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,/elevatedusage.${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.