ClawHosters
by Daniel Samer
6 min read
40,214 exposed OpenClaw instances. That's the number SecurityScorecard published last month. Of those, 63% are vulnerable, and 12,812 are confirmed exploitable via remote code execution. Let that sink in for a second.
Peter Steinberger, the creator of OpenClaw himself, put it bluntly: "Most non-techies should not install this. It's not finished, I know about the sharp edges." And yet thousands of people spin up containers without changing a single default.
I've personally watched someone extract API keys from an unsecured OpenClaw instance in 30 seconds. Not a sophisticated attack. Just a WebSocket connection and a crafted parameter. That's CVE-2026-25253 (CVSS 8.8), and it works on anything running default configs.
So here's how to actually lock things down.
Dockerfile Security: Stop Running as Root
58% of containers run as root by default. OpenClaw's Docker image is no exception.
Running as root means any exploit that escapes the application process has full control over the container, and potentially the host. Fix this first.
services:
openclaw:
user: "1000:1000"
security_opt:
- no-new-privileges:true
cap_drop:
- ALL
That cap_drop: ALL line is probably the single most impactful change you can make. It drops every Linux capability the container would otherwise inherit. The no-new-privileges flag prevents any process inside from escalating permissions through setuid binaries or similar tricks.
If your application needs specific capabilities (rare for OpenClaw), add them back individually with cap_add. But start from zero.
Container Security Best Practices: Lock the Filesystem
A read-only root filesystem stops attackers from modifying binaries, dropping malware, or planting persistence mechanisms inside your container.
services:
openclaw:
read_only: true
tmpfs:
- /tmp
- /var/run
OpenClaw needs a few writable directories for temporary files. Mount those as tmpfs (in-memory only, wiped on restart). Everything else stays read-only.
Docker Vulnerability Scanning and Image Pinning
Never use latest. I mean it.
When you pull openclaw:latest, you have zero guarantee about what's in that image. Pin to a specific digest instead.
image: openclaw/openclaw@sha256:abc123...
Netskope found over 300 trojanized Docker packages carrying LuaJIT payloads. The attack vector? Developers pulling unverified images from public registries. Pinning to a known-good digest means your builds are reproducible and you're not blindly trusting whatever showed up in latest this morning.
Run docker scout or Trivy against your images regularly. Automate it in CI if you can.
Network Isolation: Bind to Localhost Only
By default, OpenClaw's gateway listens on all interfaces. That means anyone who can reach your server can reach your AI agent.
services:
openclaw:
ports:
- "127.0.0.1:8080:8080"
networks:
- openclaw-internal
networks:
openclaw-internal:
driver: bridge
internal: true
Binding to 127.0.0.1 means only local traffic reaches the gateway. Put nginx or Caddy in front for TLS termination and access control.
Use a dedicated bridge network with internal: true so containers on that network can't reach the internet directly. Your AI agent doesn't need to browse the web.
Restrict What OpenClaw Can Actually Do
This is the part most people skip, and honestly it's the part that matters most.
OpenClaw has a system.run tool that can execute arbitrary commands. If you don't restrict it, your AI agent can do anything the container user can do.
{
"tool_policy": {
"allowed": ["read_file", "write_file", "search"],
"denied": ["system.run"]
},
"workspace": {
"only": true,
"deny_patterns": [".ssh/**", ".aws/**", ".env*", "*.pem"]
}
}
Set workspaceOnly: true to keep file access within the project directory. Deny patterns block access to sensitive directories. And a tool policy allowlist ensures only the tools you explicitly approve are available.
As Jeremy Turner from SecurityScorecard warned: "Don't just blindly download one of these things and start using it on a system that has access to your whole personal life."
Resource Limits: Don't Let One Container Eat Your Server
services:
openclaw:
deploy:
resources:
limits:
cpus: "2.0"
memory: 2G
ulimits:
nofile:
soft: 1024
hard: 2048
Without limits, a misbehaving agent or a denial-of-service attack can consume all system resources. Hard limits prevent that.
Or Just Skip All of This
Here's the honest truth. Every hardening step I've described above is already built into ClawHosters managed infrastructure. Hetzner Cloud Firewall with whitelist-only access, Docker daemon hardening with no-new-privileges, fail2ban, SSH key-only authentication, automatic security updates.
Self-hosting OpenClaw securely takes 20 to 40 hours of initial setup and 2 to 4 hours per week of ongoing maintenance. Patching, monitoring, log auditing. That's real time you could spend building things instead.
Check out our security overview for the full breakdown, or read the self-hosted vs managed comparison if you're still deciding. We also have a free trial if you want to try it yourself.
