OpenClaw Security Risks Are Real — Here's How to Actually Fix Them

Introduction

OpenClaw's security risks are well-documented at this point. Exposed instances numbered in the tens of thousands by February 2026. Over 400 malicious skills were found on ClawHub. CVE-2026-25253 demonstrated one-click remote code execution through crafted links. Fake OpenClaw installers distributed credential-stealing malware. The attack surface is real and it's broad.

Most articles about OpenClaw security risks stop at describing the problems. This guide focuses exclusively on fixing them — with specific commands, configurations, and architectural decisions. If you're running OpenClaw in production (or planning to), this is your hardening playbook.

The Threat Landscape in Plain English

Before diving into fixes, understand what you're defending against. OpenClaw faces eight distinct threat categories:

1. Network exposure: The gateway port (18789) is reachable from the internet, letting anyone send commands to your agent
2. Credential theft: API keys stored in plaintext files are readable by any process (or malware) on the machine
3. Prompt injection: Malicious instructions hidden in emails, documents, or web pages that the agent processes and follows
4. Supply chain attacks: Malicious skills from ClawHub that exfiltrate data, install backdoors, or mine cryptocurrency
5. Container escape: If running in Docker, a compromised agent process could potentially access the host system
6. Memory poisoning: Malicious content that gets written into the agent's permanent memory files through the pre-action flush
7. Financial drain: Runaway API costs from agents stuck in loops or processing enormous contexts
8. Fake distributions: Trojanized OpenClaw installers distributed through unofficial channels

Not every deployment faces all eight threats. A personal agent on a Mac Mini behind a home router faces different risks than a company running 20 agents on a cloud VPS with public IPs. Prioritize fixes based on your exposure.

Fix 1: Exposed Ports

The problem: OpenClaw's gateway listens on port 18789. Over 21,000 instances were found publicly exposed in early 2026 — many without any authentication. An attacker who can reach this port can send arbitrary commands to your agent.

Fix for VPS/cloud deployments

Configure your firewall to block external access to port 18789. On Ubuntu/Debian with ufw:

sudo ufw deny 18789
sudo ufw allow from 127.0.0.1 to any port 18789

Access your agent only through SSH tunneling or a VPN. If you need remote access, put a reverse proxy (Nginx, Caddy) in front with HTTP basic auth or OAuth at minimum.

Fix for Mac Mini at home

Your home router's NAT already blocks inbound connections unless you've explicitly forwarded port 18789. Don't forward it. If you need remote access, use a VPN (Tailscale is the easiest option — free for personal use, 5-minute setup).

Fix for Docker deployments

Bind the port to localhost only in your docker-compose.yml:

ports:
  - "127.0.0.1:18789:18789"

This ensures the port is only reachable from the host machine, not from the network.

Fix 2: Credential Management

The problem: API keys for Anthropic, OpenAI, messaging platforms, and external services are often stored in plaintext configuration files. Any malware, malicious skill, or misconfigured process can read them.

Minimum viable fix: environment variables

Move credentials from config files to environment variables. In your shell profile or a .env file (with restricted permissions):

export ANTHROPIC_API_KEY="sk-ant-..."
export TELEGRAM_BOT_TOKEN="..."
chmod 600 .env

Better fix: secrets manager

For team deployments, use a proper secrets manager: HashiCorp Vault, AWS Secrets Manager, or Doppler. The agent reads credentials at startup from the secrets manager instead of the filesystem. If a credential is compromised, you rotate it in one place.

Best practice: scoped API keys

Don't give your agent a single all-powerful API key. Create separate keys with limited scopes for each integration. Your email-reading key shouldn't also be able to send messages. Your CRM read key shouldn't be able to delete records.

Fix 3: Prompt Injection Defense

The problem: When your agent processes external content (emails, documents, web pages, messages from unknown users), that content can contain hidden instructions. A carefully crafted email can tell your agent to forward all future emails to an attacker, change its behavior, or exfiltrate data.

Architectural defense: input/output separation

The most effective defense is architectural. Separate the agent's instruction channel (your messages via Telegram/WhatsApp) from its data channel (emails, documents, web content it processes). Content from external sources should be treated as data, never as instructions.

In practice, this means:

• Configure your soul.md to explicitly instruct the agent to never follow instructions found in external documents
• When the agent processes external content, wrap it in clear delimiter tags that the model is instructed to treat as data
• Never pipe raw external content directly into the system prompt

Monitoring defense: output auditing

Monitor what your agent sends and to whom. If it suddenly starts forwarding emails to an unknown address or accessing files it doesn't normally touch, that's a red flag. Log all outbound actions and review them regularly.

Scope defense: least privilege

An agent that can only read emails but not send them can't be tricked into forwarding your inbox. An agent without shell access can't be tricked into running commands. Remove capabilities your agent doesn't need for its specific workflows.

Fix 4: Malicious Skill Protection

The problem: ClawHub's skill marketplace had 400+ malicious skills discovered in early 2026. These included data exfiltration tools, crypto miners, and backdoor installers. The VirusTotal integration catches known malware but misses novel attacks.

Rule 1: Minimize skills

Every skill you install is code running with your agent's permissions. The fewer skills you have, the smaller your attack surface. Most business workflows can be built with OpenClaw's built-in capabilities (shell commands, HTTP requests, file operations) without third-party skills.

Rule 2: Read the code

Before installing any ClawHub skill, read its source code. The skills are typically small — a few hundred lines of TypeScript. Look for suspicious patterns: outbound network calls to unknown domains, file access outside the workspace, obfuscated code, or encoded strings.

Rule 3: Pin versions

Don't auto-update skills. A legitimate skill today could be compromised tomorrow through a supply chain attack on its maintainer's account. Pin to specific versions and review changes before updating.

Rule 4: Isolate skill execution

Run skills in a separate container or with reduced filesystem access. Docker's --read-only flag and explicit volume mounts can limit what a skill can access even if it turns malicious.

Fix 5: Container Isolation

The problem: A compromised agent process can access everything on the host machine unless properly isolated. This includes other agents' data, system files, and network resources.

Docker isolation setup

Run each agent in its own Docker container with these constraints:

services:
  agent-1:
    image: openclaw/agent:latest
    read_only: true
    tmpfs:
      - /tmp
    volumes:
      - ./agent-1-workspace:/workspace
    deploy:
      resources:
        limits:
          cpus: '1.0'
          memory: 512M
    networks:
      - agent-net
    security_opt:
      - no-new-privileges:true

Key constraints:

• read_only: Filesystem is read-only except for explicitly mounted volumes
• Resource limits: CPU and memory caps prevent runaway processes
• Separate network: Agents can't access each other's containers or the host network unless explicitly allowed
• no-new-privileges: Prevents privilege escalation inside the container

Fix 6: Memory File Poisoning

The problem: When OpenClaw's context window fills up, it flushes important information to memory files (markdown files in your workspace). If malicious content was processed during the conversation, it can get persisted into permanent memory. The agent then reads that poisoned memory file in future conversations and follows the injected instructions.

Prevention: review memory files

Periodically review your agent's memory files (soul.md, knowledge files, conversation logs). Look for content that shouldn't be there — unexpected instructions, URLs to unfamiliar domains, or behavioral changes you didn't configure.

Prevention: read-only sensitive memory

Make your soul.md and core configuration files read-only. The agent can read them but can't modify them. This prevents a prompt injection attack from rewriting your agent's identity or core instructions.

chmod 444 workspace/soul.md
chmod 444 workspace/heartbeat.md

Detection: memory file checksums

Hash your critical memory files and alert on changes. A simple cron job that checks file hashes daily catches unauthorized modifications:

# Generate baseline
sha256sum workspace/soul.md > /var/checksums/soul.md.sha256

# Check daily (add to crontab)
sha256sum -c /var/checksums/soul.md.sha256 || alert "soul.md modified"

Fix 7: Runaway API Costs

The problem: Agents stuck in reasoning loops, processing massive documents, or simply running at higher volume than expected can generate hundreds of dollars in API costs per day.

Provider-level limits

Set monthly spending caps at your AI provider (Anthropic, OpenAI). Most providers support this in their dashboard. Set the limit below your pain threshold — you can always raise it.

Agent-level limits

Configure per-agent daily token budgets. When an agent hits its budget, it pauses and notifies you instead of continuing. This is especially important for heartbeat tasks that run automatically 24/7.

Context window management

Large context windows are expensive. An agent that sends 100K tokens per API call costs 10x more than one that sends 10K. Use OpenClaw's two-tier processing to avoid sending unnecessary context to the LLM. Run deterministic scripts for condition checks; only invoke the LLM when reasoning is actually needed.

Fix 8: Monitoring and Alerting

The problem: Without monitoring, you won't know when an agent is compromised, misbehaving, or burning through your budget until the damage is done.

What to monitor

• API spend: Daily and hourly cost tracking per agent. Alert at 2x normal spend.
• Outbound requests: Log every HTTP request the agent makes. Alert on requests to new/unknown domains.
• File access: Log file reads and writes. Alert on access outside the agent's workspace.
• Message volume: Track messages sent by the agent. Alert on unusual spikes.
• Error rate: Track failed tool calls and API errors. A spike in errors may indicate a problem or an attack.
• Process health: Monitor CPU, memory, and uptime. Alert on crashes or resource exhaustion.

Simple monitoring setup

For small deployments, a daily digest of agent activity (messages sent, API calls made, total spend, any errors) is enough. Configure your agent's heartbeat to produce a daily self-report and send it to a monitoring channel separate from your main agent channel.

The Hardening Checklist

Print this. Check every box before going to production:

Wrapping Up

OpenClaw's security risks are real but they're fixable. None of the mitigations in this guide require exotic tools or deep security expertise — they're standard practices applied to a specific system. Firewall a port, manage credentials properly, isolate processes in containers, monitor what the system is doing, and don't run code you haven't reviewed.

The agents that get compromised are the ones deployed with default settings and never reviewed. An afternoon of hardening work separates a secure deployment from a liability.