OpenClaw Security Hardening

OpenClaw Security Hardening Guide — Protect Your VPS & Agent (2026) 🔒 Security Guide OpenClaw Security Hardening CVE-2026-25253 affected 17,500+ exposed instances. 63% of publicly accessible OpenClaw deployments had critical…

OpenClaw Security Hardening Guide — Protect Your VPS & Agent (2026)
🔒 Security Guide

OpenClaw Security Hardening

CVE-2026-25253 affected 17,500+ exposed instances. 63% of publicly accessible OpenClaw deployments had critical misconfigurations. Here’s how to not be one of them.

🛡️ Covers Server + Agent + API security
⏱ Time needed ~45 minutes
✅ Updated April 2026
17,500+

Publicly exposed OpenClaw instances found by researchers in early 2026

63%

Had at least one critical misconfiguration enabling unauthorized access

341

Malicious skills identified on ClawHub — including credential-stealing malware

Section 01

Secure the Gateway Critical

The Gateway is OpenClaw’s entry point — leaving it exposed or with a weak token is the #1 security mistake.

Set a strong gateway auth token

Your .env file must contain a strong, unique token. This token is required to connect any client to your Gateway.

# Generate a cryptographically secure token $ openssl rand -hex 32 # Copy the output and add it to your .env: GATEWAY_AUTH_TOKEN=your-generated-token-here
Never Use Default or Simple Tokens

Tokens like “password123”, “openclaw”, or anything short are trivially brute-forceable. Use at least 32 random characters. The openssl rand -hex 32 command generates an ideal token.

Do NOT expose port 3000 to the internet

Your Docker Compose file should bind OpenClaw’s port to localhost only:

~/openclaw/docker-compose.yml — correct binding
ports: – “127.0.0.1:3000:3000# ✓ Correct — localhost only – “0.0.0.0:3000:3000# ✗ WRONG — exposed to internet – “3000:3000# ✗ WRONG — also exposed to internet

Enable the gateway password or token requirement

In your .env file, ensure authentication is required for all connections:

# At minimum, set one of these in .env GATEWAY_AUTH_TOKEN=your-strong-token # Or password-based (less preferred): # GATEWAY_AUTH_PASSWORD=your-strong-password
Section 02

Harden SSH Access Critical

SSH is your server’s front door. Switch from passwords to keys, and lock down who can get in.

Step 1: Generate an SSH key pair on your local machine

# Run this on your LOCAL machine, not the server local $ ssh-keygen -t ed25519 -C “openclaw-vps” # Press Enter to accept the default location (~/.ssh/id_ed25519) # Set a passphrase for extra security (recommended)

Step 2: Copy your public key to the server

local $ ssh-copy-id -i ~/.ssh/id_ed25519.pub root@YOUR_SERVER_IP # Or manually: cat ~/.ssh/id_ed25519.pub | ssh root@IP “mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys”

Step 3: Test key-based login before disabling passwords

# In a NEW terminal window — test this works BEFORE editing sshd_config local $ ssh -i ~/.ssh/id_ed25519 root@YOUR_SERVER_IP # If you get in without a password prompt, proceed to the next step

Step 4: Disable password authentication

$ sudo nano /etc/ssh/sshd_config
Edit these lines in /etc/ssh/sshd_config
PasswordAuthentication no PermitRootLogin no PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys # Optional: restrict SSH to a non-standard port (e.g. 2222) Port 22
$ sudo systemctl restart sshd
Don’t Lock Yourself Out

Always test key-based SSH login in a separate window BEFORE restarting sshd and disabling passwords. If you lock yourself out, you’ll need to use your hosting provider’s console access to recover.

Section 03

Configure UFW Firewall High

UFW (Uncomplicated Firewall) is Ubuntu’s built-in firewall. Configure it to allow only necessary traffic.

# Enable UFW $ sudo ufw default deny incoming $ sudo ufw default allow outgoing # Allow SSH (critical — do this BEFORE enabling UFW) $ sudo ufw allow 22/tcp # If you’re running a web server or Nginx reverse proxy $ sudo ufw allow 80/tcp $ sudo ufw allow 443/tcp # Enable the firewall $ sudo ufw enable # Verify the rules $ sudo ufw status verbose
Do NOT Open Port 3000

Port 3000 (OpenClaw’s Control UI) should never be open in your firewall. Access it exclusively via SSH tunnel. Opening this port exposes your entire agent interface to the internet.

Install and configure fail2ban

Fail2ban automatically bans IP addresses that show malicious behaviour — like repeated failed SSH logins.

$ sudo apt install -y fail2ban $ sudo systemctl enable fail2ban $ sudo systemctl start fail2ban
/etc/fail2ban/jail.local (create this file)
[DEFAULT] bantime = 1h findtime = 10m maxretry = 5 [sshd] enabled = true
$ sudo systemctl restart fail2ban
Section 04

Access the Control UI Securely High

There are two secure ways to access OpenClaw’s Control UI — SSH tunnel (simplest) or Tailscale (best for teams).

Option A: SSH Tunnel (recommended for individuals)

Run this on your local machine whenever you need to access the Control UI:

local $ ssh -L 3000:localhost:3000 -N your-user@YOUR_SERVER_IP

Keep this terminal open. Then visit http://localhost:3000 in your browser. Close the terminal when done.

Option B: Tailscale (recommended for persistent access or teams)

Tailscale creates a private encrypted network between your devices and your VPS.

# On your server $ curl -fsSL https://tailscale.com/install.sh | sh $ sudo tailscale up # Authenticate via the URL it provides # Your server gets a Tailscale IP (e.g. 100.x.x.x)
Reconfigure .env to listen on Tailscale IP only
# In docker-compose.yml, bind to your Tailscale IP ports: – “100.x.x.x:3000:3000

Now access the Control UI at http://100.x.x.x:3000 from any device on your Tailscale network.

Tailscale Is Excellent for Teams

Multiple team members can securely access the same OpenClaw instance without each running an SSH tunnel. No port forwarding, no firewall rules — Tailscale’s zero-config mesh network handles everything.

Section 05

Protect Your API Keys Critical

Your AI API keys are the most sensitive data on your server. Any skill installed on OpenClaw has potential access to the .env file — including malicious ones.

File permissions

# Only the owner can read/write the .env file $ chmod 600 ~/openclaw/.env $ ls -la ~/openclaw/.env # Should show: -rw——- (not readable by others)

Set strict spending limits on every AI provider

  • Anthropic Console
    console.anthropic.com → Settings → Limits → Set a monthly spend cap
  • OpenAI Platform
    platform.openai.com → Settings → Limits → Set usage limit
  • Google AI Studio
    Free tier has built-in quotas; for paid use, set billing limits in Google Cloud Console

Consider using separate API keys per deployment

Create a dedicated API key for OpenClaw rather than using your main account key. If the key is ever compromised, you can rotate it without affecting other tools.

Never Commit .env to Version Control

If you’re using Git to manage your OpenClaw configuration, ensure .env is in your .gitignore. Hundreds of API keys have been compromised this way.

# Add to .gitignore if using Git $ echo “.env” >> ~/openclaw/.gitignore
Section 06

Vet ClawHub Skills Before Installing High

In January 2026, a campaign called ClawHavoc distributed credential-stealing malware through 341 malicious ClawHub skills. Here’s how to protect yourself.

Red flags to look for before installing a skill

  • Unverified publisher
    Prefer skills from verified publishers (blue checkmark). Be extremely cautious with anonymous or newly registered publishers.
  • Suspicious permissions
    A “YouTube downloader” skill that requests file system access and network permissions to arbitrary IPs is a red flag. Permissions should match the stated purpose.
  • Impersonating popular tools
    The ClawHavoc campaign specifically impersonated crypto utilities, YouTube tools, and prediction market bots. If a skill claims to do something very popular, verify the publisher carefully.
  • No source code or recent activity
    Open source skills you can audit are far safer. Check if the skill has been updated recently and whether it has community reviews.
  • Very new or zero reviews
    A skill published yesterday with zero reviews and high install counts is suspicious.
Best Practice: Only Install What You Need

Start with zero skills and add only what you actually use. Each skill you install increases your attack surface. Review your installed skills quarterly and remove any you no longer use.

Section 07

Stay Updated on CVEs Critical

When CVE-2026-25253 was disclosed, managed hosting providers patched their entire fleet within hours. Self-hosters who weren’t monitoring went weeks without patching. Automate this.

Create an automated weekly update script

~/openclaw/update.sh
$ cat > ~/openclaw/update.sh << 'EOF' #!/bin/bash cd ~/openclaw # Pull latest OpenClaw image docker compose pull # Restart with new image if changed docker compose up -d # Clean up old images docker image prune -f echo “OpenClaw updated: $(date)” >> ~/openclaw/update.log EOF $ chmod +x ~/openclaw/update.sh

Schedule it with cron (runs every Sunday at 3 AM)

$ crontab -e # Add this line: 0 3 * * 0 /home/openclaw/openclaw/update.sh >> /home/openclaw/openclaw/update.log 2>&1

Where to monitor for OpenClaw security advisories

  • OpenClaw GitHub repository
    Watch the repo and enable security advisory notifications in GitHub settings
  • OpenClaw Discord #security channel
    Critical vulnerabilities are announced here first
  • NVD (National Vulnerability Database)
    Search for “openclaw” at nvd.nist.gov for official CVE listings
Section 08

Complete Security Checklist

Use this as your final verification before going live. Check off each item.

  • Gateway auth token set — Strong 32+ character token in .env
  • Port 3000 NOT open in firewall — Access via SSH tunnel only
  • Port binding is 127.0.0.1:3000 — Not 0.0.0.0:3000 in docker-compose.yml
  • SSH keys enabled, passwords disabled — PasswordAuthentication no in sshd_config
  • UFW firewall active — Only ports 22, 80, 443 open (and 22 only to your IP ideally)
  • fail2ban running — sudo systemctl status fail2ban
  • .env file permissions set to 600 — chmod 600 .env
  • AI provider spending limits set — For all providers you use
  • Root login disabled — PermitRootLogin no in sshd_config
  • Weekly update cron job active — crontab -l to verify
  • Only necessary skills installed — Remove any unused skills
  • GitHub security advisories enabled — Watch the OpenClaw repo

Server Secured — Next Steps

With security in place, protect yourself from the other major risk: runaway AI API costs from agent loops.

Prevent Runaway API Costs → ← Back to Installation Guide