OpenClaw's growth in 2026 has been extraordinary — and so has the community pushback on its security posture. Threads on r/selfhosted and Hacker News have repeatedly surfaced warnings about self-hosted deployments, ranging from mild configuration concerns to documented security incidents. This roundup captures what the community is saying and what you should actually do about it.
What's Driving the Concern
OpenClaw is different from most software you self-host. A reverse proxy or media server has a clear, bounded attack surface. OpenClaw is an autonomous agent that:
- Executes shell commands and filesystem operations
- Processes untrusted external input (web content, emails, webhook payloads)
- Installs and runs third-party skills (code from ClawHub)
- Holds live credentials for external services
Security researchers have coined the phrase "dual supply chain risk" to describe the combination: untrusted instructions meeting executable skills in the same runtime, all running under your credentials. If any part of that chain is compromised, the blast radius can extend to everything the agent can reach.
Documented Incidents in 2026
The community isn't just theorizing. Several concrete incidents have shaped the current conversation:
ClawHavoc (supply chain attack): Attackers uploaded over 800 malicious skills to ClawHub disguised as legitimate utilities. Users who installed affected skills exposed their systems to credential theft and lateral movement. The ClawHub team has since implemented stricter review, but the incident underscored the risk of installing skills from unverified publishers.
ClawJacked flaw: A high-severity vulnerability allowed malicious websites to hijack OpenClaw agents via prompt injection through web content. Fixed in v2026.2.26. If you haven't upgraded past that version, do it now.
CVE-2026-32922 (CVSS 9.9): A critical privilege escalation vulnerability in versions prior to v2026.3.11 allowed remote code execution via token management flaws. Patched — but a reminder that staying current on OpenClaw releases isn't optional.
Exposed instances: Security researchers found over 42,000 publicly accessible OpenClaw gateway instances with default or minimal hardening, many with gateway ports (18789, 18793) open to the internet without authentication.
The Top Mistakes Self-Hosters Make
Threads on r/selfhosted and r/OpenClawInstall consistently point to the same configuration errors:
Running as root. This is the single most dangerous mistake. If your OpenClaw process is compromised, an attacker inherits root on your machine. Run under a dedicated non-privileged user.
Exposed gateway ports. The default gateway port (18789) and Canvas host port (18793) should not be publicly accessible. Bind to localhost and use a reverse proxy with authentication, or restrict access via firewall to known IPs only.
Broad filesystem access. Unless your agent genuinely needs to read and write across your entire drive, restrict its workspace. Set tools.filesystem.workspaceOnly: true in your config to limit the agent to its designated directory.
Default SSH on port 22 with password auth. This isn't OpenClaw-specific, but a compromised VPS running OpenClaw is a particularly bad outcome. Disable password auth, use key-based login, consider moving SSH to a non-standard port.
No approval gates on high-risk tools. The new requireApproval hook in v2026.3.28 exists for a reason — use it. Wrap shell execution and file writes in plugin approval flows so destructive actions require explicit confirmation.
What v2026.3.28 Gets Right
The latest release includes several security-relevant changes worth noting:
- Extended web search key audit (#56540) now recognizes Gemini, Grok/xAI, Kimi, Moonshot, and OpenRouter credentials, making it harder to accidentally expose keys through web search config leaks.
- Plugin approval hooks (#55339) let you gate any tool call behind user confirmation — across Telegram, Discord, exec overlay, or
/approve. - ACPX agent registry hardening (#28321) stops unknown ACP agent IDs from falling through to raw
--agentcommand execution on the MCP-proxy path. - Control UI config security (fixes #55322) keeps sensitive raw config hidden by default, requiring explicit reveal-to-edit.
None of these make OpenClaw risk-free, but they close real attack vectors that were previously open.
Practical Hardening Checklist
Based on community consensus and the official docs, here's a minimum viable hardening setup for self-hosted OpenClaw:
System level:
- [ ] Run OpenClaw under a dedicated non-root user
- [ ] Restrict gateway ports behind a firewall or VPN (not open to internet)
- [ ] Use a reverse proxy with basic auth or mTLS for remote access
- [ ] Enable automatic security updates on your host
OpenClaw config:
- [ ] Set
tools.profile: messagingto limit fresh agents from shell/filesystem access - [ ] Enable
tools.filesystem.workspaceOnly: trueunless broad access is required - [ ] Use the secrets system for credentials — never inline API keys in config
- [ ] Add
requireApprovalhooks for destructive tool calls - [ ] Only install skills from trusted publishers; audit ClawHub installs
Operational:
- [ ] Stay current on OpenClaw releases — patch fast when CVEs are published
- [ ] Monitor agent logs for unexpected shell executions or outbound requests
- [ ] Keep API spending limits set at your providers (OpenAI, Anthropic, etc.)
The Core Tension
The HN threads capture a real debate: OpenClaw's power comes from the same things that make it risky. An agent that can only send read-only messages isn't very useful. An agent that can read files, run commands, and install extensions is genuinely powerful — and genuinely dangerous if misconfigured or compromised.
The community consensus is not "don't use it" but "understand what you're exposing." Treat an OpenClaw deployment like any other privileged service: isolate it, gate it, monitor it, and patch it.
For a deeper look at hardening, the OpenClaw security docs and Microsoft's running-openclaw-safely guide are both worth reading.