OpenClaw Security: How to Install It Without Getting Hacked

In January 2026, OpenClaw crossed 100,000 GitHub stars in under two weeks. By February, security researchers had found over 21,000 publicly exposed instances leaking API keys and OAuth tokens. A critical remote code execution vulnerability scored 8.8 on the CVSS scale. And 341 malicious skills had already been planted in the official marketplace. This is the story of what went wrong, what the actual attack surface looks like, and how to run OpenClaw without becoming the next headline.

What OpenClaw Actually Is

OpenClaw is an open-source personal AI assistant that runs locally on your machine. It connects to chat apps you already use (WhatsApp, Telegram, Discord, Slack, Signal, iMessage) and gives you a persistent, autonomous agent that can browse the web, run shell commands, manage files, and integrate with 50+ services like Gmail, GitHub, Spotify, and Obsidian.

It works with Anthropic Claude, OpenAI models, or local LLMs. It learns your preferences over time, runs cron jobs, monitors things in the background, and can even write and update its own skills. The extensibility is impressive. The attack surface is enormous.

The Security Timeline: What Happened

The incidents came fast. Here's the condensed timeline:

• January 27–29, 2026: The "ClawHavoc" campaign. Attackers uploaded 341 malicious skills to ClawHub, OpenClaw's public marketplace. The skills looked legitimate, with professional documentation and innocuous names. Once installed, they deployed keyloggers on Windows and Atomic Stealer malware on macOS. Roughly 12% of the entire registry (2,857 entries at the time) was compromised.
• January 30, 2026: CVE-2026-25253 was patched. CVSS 8.8. The vulnerability allowed one-click remote code execution: an attacker creates a malicious webpage, the victim visits it, and the OpenClaw gateway's authentication token leaks via cross-site WebSocket hijacking. Full administrative control in milliseconds.
• February 3, 2026: Public disclosure of CVE-2026-25253 plus two additional command injection vulnerabilities.
• February 2026: The Moltbot breach. A third-party service in the OpenClaw ecosystem was compromised, exposing 35,000 email addresses and 1.5 million agent API tokens.
• February 2026: Security researchers identified 21,639 publicly accessible OpenClaw instances in the first wave — a number that grew to over 42,000 by the time CVE-2026-25253 was publicly disclosed. Many were leaking API keys, OAuth tokens, and plaintext credentials.

Every major security vendor weighed in. Palo Alto Networks, Trend Micro, Kaspersky, and Cisco all published analyses. The consensus: OpenClaw is powerful, but running it with default settings on a public network is reckless.

The Three Attack Vectors That Matter

1. Exposed Gateway Instances

OpenClaw runs a gateway server on port 18789. If that port is reachable from the internet, with a weak or default token, an attacker gets full control of your agent. They can read your messages, access your connected services, and execute arbitrary commands on your machine.

The first step is to never bind to 0.0.0.0. Bind to localhost only. Use SSH tunneling or an identity-aware VPN like Tailscale for remote access.

Important caveat: localhost binding alone does not protect against CVE-2026-25253. That vulnerability works by tricking your own browser into acting as a bridge to your local gateway — so even an instance bound to 127.0.0.1 can be fully compromised by visiting a single malicious webpage. Patching to version 2026.1.29 or later is essential. Treat network isolation as one layer of a defence-in-depth strategy, not a complete fix on its own.

2. Malicious Skills from ClawHub

Skills in OpenClaw execute arbitrary code, including shell commands. The ClawHavoc campaign proved that the marketplace has no effective vetting process. A skill with a clean README and a plausible name can install a keylogger.

Treat every skill like an untrusted npm package from an unknown author. Audit the source before installing. Run new skills in sandboxed containers with minimal permissions until you've verified them.

3. Prompt Injection and Indirect Attacks

OpenClaw agents browse the web, read files, and process messages from external sources. Every one of those inputs is a potential prompt injection vector. A malicious web page, a crafted email, or a poisoned document can instruct the agent to exfiltrate data or run commands.

This is the hardest vector to close completely. The mitigations are layered: restrict tool access, sandbox aggressively, and never give an agent more permissions than it needs.

Hardening Guide: Step by Step

If you're going to run OpenClaw, here's the minimum you should do before your first session. All configuration changes below go in ~/.openclaw/openclaw.json, the main config file. You can also edit it via openclaw config get/set from the command line.

Lock Down the Gateway

In your openclaw.json, bind to loopback only and set a strong authentication token:

// ~/.openclaw/openclaw.json
gateway: {
  bind: "loopback",
  port: 18789,
  auth: { token: "YOUR_SECRET_TOKEN" }
}

Rotate gateway.auth.token regularly. Never hard-code tokens in containers. Use Kubernetes Secrets or a vault like HashiCorp Vault. Set up firewall rules to block port 18789 from any non-local traffic.

Restrict Tool Access

OpenClaw's default tool permissions are too broad. Use explicit allowlists:

// ~/.openclaw/openclaw.json
tools.allow: ["memory_get", "browser.search"]
tools.elevated: []

Deny rules override allow rules. Withhold exec and apply_patch unless strictly required. Block destructive capabilities like write, edit, and process by default, then grant them per-agent only where justified.

Enable Sandboxing

OpenClaw offers three sandbox levels in agents.defaults.sandbox:

• Off — no isolation. Only acceptable for single-user local setups where you trust yourself not to install anything malicious.
• Non-main (default) — group chats and secondary threads run isolated; your primary session runs on the host.
• All — every tool call runs inside a Docker container. This is the right choice for anything connected to external channels.

For any agent that processes messages from other people, use "all". No exceptions.

Secure the State Directory

The ~/.openclaw directory contains your credentials, conversation history, agent memory, and cached OAuth tokens. Lock it down:

chmod 700 ~/.openclaw

Scan this directory regularly for overly permissive files. Never store secrets in plaintext in AGENTS.md or SOUL.md. Use OpenClaw's built-in secret store or mount external vault tokens as read-only volumes.

Configure Channel Policies

Set strict DM policies on every messaging channel:

// ~/.openclaw/openclaw.json
channels: {
  telegram: {
    enabled: true,
    botToken: "TOKEN",
    dmPolicy: "pairing",
    allowFrom: ["tg:123"]
  }
}

The "pairing" policy requires a one-time confirmation code from unknown contacts. Never use "open" unless you have a very specific reason and understand the risk. Require explicit mentions in group chats.

Run the Built-in Security Audit

OpenClaw ships with diagnostic and audit tools. Run them after every configuration change and every new skill installation:

openclaw doctor --deep
openclaw security audit --fix
openclaw sandbox explain

Docker Deployment: The Safer Path

Running OpenClaw directly on your primary machine is a risk. A compromised agent has access to everything your user account can reach. Docker provides meaningful isolation.

Key container hardening measures:

• Run as a non-root user (runAsUser: 1000)
• Use a read-only filesystem where possible
• Drop all capabilities and add back only what's needed
• Mount volumes with strict, narrow paths
• Restrict outbound network access to only required domains

For production or team deployments, a Kubernetes setup with separate pods per agent, persistent volume claims for state, and proper RBAC gives you the isolation guarantees that a single Docker container cannot.

The Corporate Risk: Shadow AI Agents

The biggest threat OpenClaw poses to organisations is not technical. It's organisational.

When an employee connects OpenClaw to their work Slack, Gmail, or Google Drive, the agent gains access to Slack messages and files, emails and calendar entries, cloud-stored documents, and OAuth tokens that enable lateral movement across services. Traditional security tools don't catch this. Endpoint security sees processes but doesn't understand agent behaviour. Network tools see API calls but can't distinguish legitimate automation from compromise. Identity systems see OAuth grants but don't flag AI agent connections as unusual.

If your team uses OpenClaw, establish a policy. Define which integrations are allowed, require sandboxing, audit OAuth grants, and make sure your security team has visibility into what agents are connected to which services.

The Deployment Checklist

Before you run OpenClaw in any environment, verify every item:

• Gateway bound to localhost only
• Strong, rotated authentication token
• Firewall rules blocking port 18789 externally
• ~/.openclaw directory at 700 permissions
• Tool allowlist configured per agent
• Sandbox mode set to "all" for external-facing agents
• DM policy set to "pairing"
• No secrets in plaintext workspace files
• openclaw security audit passing clean
• Every ClawHub skill audited before installation
• Nightly backups of state directory
• Patched to version 2026.1.29 or later (CVE-2026-25253 fix)

The Bottom Line

OpenClaw is a genuinely useful tool. A persistent AI agent that runs locally, connects to your existing chat apps, and integrates with dozens of services solves a real problem. But its power is exactly what makes it dangerous when misconfigured.

The defaults are not secure enough for production use. The marketplace has been compromised. The gateway has had critical vulnerabilities. Running it without hardening is like running an SSH server with password authentication on the open internet: it might work for a while, but the odds are not in your favour.

Take the time to lock it down properly. The hardening steps above are not optional. They're the minimum.