OpenClaw Security: 5 Self-Hosting Risks and How to Avoid Them

OpenClaw is a powerful multi-platform AI agent framework that lets you run intelligent chatbots on WhatsApp, Telegram, and Discord from a single installation. It connects to major AI providers like Anthropic (Claude), OpenAI (GPT), and Google (Gemini), making it one of the most flexible tools available for deploying AI agents across messaging platforms.

But OpenClaw security is a real concern. The framework stores API keys, bot tokens, and session credentials in plaintext configuration files on whatever server it runs on. If that server is misconfigured, and most self-hosted servers are, those secrets are exposed. In February 2026, the OpenClaw community learned exactly how dangerous that exposure can be.

If you are evaluating what OpenClaw is and whether to self-host it, security should be the first thing you think about. This guide explains the risks, the most common mistakes, and how managed hosting eliminates them.

The OpenClaw Security Landscape in 2026

In early February 2026, an infostealer malware campaign specifically targeted OpenClaw installations. The malware scanned for the ~/.openclaw/openclaw.json configuration file, which contains API keys for AI providers, bot tokens for Telegram and Discord, and gateway authentication tokens. Compromised API keys were used to generate thousands of dollars in fraudulent AI API charges before operators realized what had happened.

The attack vector was straightforward. Many OpenClaw users run the framework on cloud VPS instances with default configurations: root SSH access with password authentication, no firewall, and the OpenClaw gateway port exposed to the public internet. The infostealer exploited weak SSH credentials to gain access, read the config file, and exfiltrate every secret it contained.

This was not a vulnerability in OpenClaw itself. OpenClaw's code is sound. The vulnerability was in how people deploy it. Self-hosting any application that handles sensitive credentials requires hardened infrastructure, and most users, even technical ones, skip critical steps.

Common Attack Vectors Against OpenClaw Installations

• SSH brute-force attacks against servers using password authentication
• Exposed gateway ports (default 18789 or custom) accessible without authentication from the public internet
• Config file theft via compromised SSH access, since openclaw.json contains all secrets in plaintext
• Credential harvesting from WhatsApp session files stored at ~/.openclaw/credentials/
• Supply chain attacks from running outdated versions of Node.js or OpenClaw with known vulnerabilities

5 Most Common Self-Hosting Security Mistakes

These are the mistakes that lead to compromised OpenClaw installations. If you self-host, every single one must be addressed.

1. Running as Root Without Isolation

Most VPS tutorials tell you to SSH in as root and start installing. Running OpenClaw as root means any exploit in the application, or in Node.js itself, has unrestricted access to the entire system. A privilege escalation vulnerability goes from theoretical to catastrophic.

What should happen: OpenClaw should run as a dedicated, unprivileged user with access only to its own files and configuration directory.

2. Exposed Ports and No Firewall

OpenClaw's gateway listens on a network port (18789 by default). If your server has no firewall rules, that port is accessible to anyone on the internet. Combine an exposed gateway with weak or missing gateway authentication, and an attacker can interact with your AI agent directly or probe for vulnerabilities in the gateway's WebSocket implementation.

What should happen: A firewall should block all inbound traffic except SSH (from known IPs) and the specific ports your application actually needs. The OpenClaw gateway port should never be exposed to the public internet.

3. Plaintext API Keys with No Protection

OpenClaw stores all configuration in ~/.openclaw/openclaw.json, a JSON5 file that contains AI provider API keys, bot tokens, and gateway auth tokens in plaintext. If anyone gains read access to this file, whether through SSH compromise, a directory traversal vulnerability, or a backup that was not encrypted, they have every secret your installation uses.

What should happen: API keys should be encrypted at rest. Access to the configuration directory should be restricted by file permissions and, ideally, protected by additional authentication layers.

4. Password-Based SSH Authentication

Password authentication on SSH is the single most exploited entry point for cloud server compromises. Automated botnets scan every IP address on the internet and attempt common username/password combinations continuously. If your server allows password-based SSH login, it is a matter of when, not if, someone gets in.

What should happen: SSH should accept key-based authentication only. Password authentication and root login should be disabled entirely.

5. Outdated Software

Running an older version of Node.js, OpenClaw, or the underlying operating system means running with known, published vulnerabilities. Attackers don't need to discover new exploits when old ones are documented in public CVE databases. The February 2026 infostealer campaign specifically targeted servers running Node versions with known security issues.

What should happen: Node.js, OpenClaw, and all system packages should be updated automatically on a regular schedule, with unattended security patches enabled.

How Managed Hosting Solves These Problems

A managed OpenClaw hosting service handles security by default, not as an afterthought. Here is what RunMyClaw does for every customer server, automatically, from the moment it is provisioned.

Automated firewall configuration. Every RunMyClaw server is provisioned with cloud-init scripts that configure UFW firewall rules before the server is even accessible. Only the ports required for operation are open. The OpenClaw gateway port is never exposed to the public internet.

SSH key-only authentication. Password authentication is disabled at provisioning. Only SSH keys controlled by the RunMyClaw infrastructure can access the server. There is no password to brute-force.

Isolated VPS per customer. Every RunMyClaw subscriber gets their own dedicated Hetzner cloud server. There is no shared infrastructure between customers. A compromise on one server cannot affect another. Compare this to shared-tenant platforms where a single breach can expose every user's data.

Zero-knowledge API key handling. With RunMyClaw's BYOK (Bring Your Own Key) model, your API key is sent directly from your browser to your dedicated server over an encrypted connection. RunMyClaw never sees, stores, or logs your key. It is written directly to your server's config. On the server, the key is stored with restricted file permissions accessible only to the OpenClaw process. This is fundamentally more secure than self-hosting, where keys are typically pasted into an unprotected config file via SSH with no access controls.

Automatic updates. OpenClaw, Node.js, and system packages are kept current through automated update mechanisms. A cron job checks for Config API updates every 6 hours. Security patches are applied without customer intervention.

No terminal exposure. RunMyClaw customers never need SSH access to their server. All configuration, including connecting Telegram bots, Discord bots, and WhatsApp, happens through the web dashboard. No terminal access means no opportunity to misconfigure the server, install compromised packages, or accidentally expose secrets.

For a detailed comparison of the self-hosted and managed approaches, see our self-hosted vs managed hosting breakdown.

Security Comparison

Security Measure	Self-Hosted (Default)	Self-Hosted (Hardened)	RunMyClaw
Firewall configured	No	Manual setup required	Automatic (cloud-init)
SSH key-only auth	No (password by default)	Manual setup required	Automatic (enforced)
API keys protected	No (plaintext JSON)	Possible with extra tooling	Zero-knowledge delivery, restricted file permissions
Non-root execution	No (root by default)	Manual setup required	Automatic (dedicated user)
Gateway port protected	No (exposed)	Manual firewall rule	Never exposed
Auto-updates	No	Manual cron setup	Automatic (every 6 hours)
Server isolation	Single server	Single server	Dedicated VPS per customer
Setup time for security	0 min (insecure)	2-4 hours	0 min (secure by default)
Ongoing maintenance	You handle it	You handle it	Handled for you

The fundamental difference: self-hosting is insecure by default and requires deliberate effort to harden. RunMyClaw is secure by default with no effort required from the customer.

What About Data Privacy?

A common concern: if RunMyClaw manages the server, does that mean RunMyClaw reads your conversations?

No. Here is exactly how data privacy works.

Your server is yours. Every customer gets a dedicated, isolated VPS. Your OpenClaw installation, your conversations, and your session data all live exclusively on your server. RunMyClaw does not share infrastructure between customers.

RunMyClaw does not access conversation content. The management layer handles provisioning, configuration, and health monitoring. It does not read, log, or analyze the messages your AI agent sends or receives. Conversation data stays between your OpenClaw instance and the messaging platforms it connects to.

Your API key, your provider, your data. With BYOK, your API key lives on your server and AI requests go directly from your server to your chosen provider (Anthropic, OpenAI, or Google). RunMyClaw never touches your AI traffic. There is no proxy, no middleman, and no message content passing through RunMyClaw infrastructure.

You control access. OpenClaw's built-in DM policies and group allowlists let you control exactly who can interact with your AI agent. These controls work the same way on a RunMyClaw server as they would on a self-hosted one.

For a full breakdown of operating costs and what you are paying for, see our OpenClaw cost analysis.

Frequently Asked Questions

Is OpenClaw safe to use?

OpenClaw itself is safe. The framework's code is well-maintained and actively developed. The security risk comes from how OpenClaw is deployed. A properly hardened server with firewall rules, SSH key authentication, encrypted secrets, and regular updates is safe. A default VPS installation with password SSH, exposed ports, and plaintext API keys is not. RunMyClaw eliminates this risk by handling all server security automatically.

Can someone steal my API keys from an OpenClaw installation?

On a misconfigured self-hosted server, yes. OpenClaw stores API keys in ~/.openclaw/openclaw.json in plaintext. If an attacker gains SSH access through brute-forced passwords, an exploited vulnerability, or stolen credentials, they can read every API key in the config file. The February 2026 infostealer campaign did exactly this. With RunMyClaw, your API key is delivered directly to your server with zero-knowledge security (RunMyClaw never sees or stores it), and the server is hardened from provisioning: SSH password authentication is disabled, a firewall blocks all unnecessary ports, and file permissions restrict access to the OpenClaw config. The key exists on your server, but the server itself is locked down far beyond what most self-hosted setups achieve.

Is my data private on RunMyClaw?

Yes. Every customer gets a dedicated, isolated VPS. RunMyClaw does not read, log, or analyze your conversations. The management layer handles server provisioning and health monitoring only. Your AI agent's conversations stay on your server and are processed by the AI provider you select (Anthropic, OpenAI, or Google) under their standard data policies.

How does RunMyClaw protect against the infostealer malware?

The February 2026 infostealer targeted plaintext config files accessible via compromised SSH. RunMyClaw prevents this attack at multiple layers: SSH password authentication is disabled (no password to brute-force), a firewall blocks all unnecessary ports, and file permissions restrict access to the OpenClaw config directory. Your API key does exist on your server (BYOK model), but the server is hardened from the moment it is provisioned, making it far more resistant to the attack vectors the infostealer exploited.

Do I need to do anything to keep my RunMyClaw server secure?

No. Security is fully automated. Firewall rules are applied at provisioning, SSH is locked down from the start, and software updates run automatically. There is no terminal access to misconfigure and no manual hardening steps to remember. You manage everything through the web dashboard.

What happens if a security vulnerability is found in OpenClaw?

RunMyClaw pushes updates to all customer servers automatically. When a new version of OpenClaw is released, whether it contains security fixes, bug fixes, or new features, the auto-update mechanism applies it without any action required from you. Self-hosted users must monitor for updates and apply them manually, which often does not happen promptly.

Secure Your AI Agent the Right Way

OpenClaw is exceptional software. The security problems are not in the framework. They are in deployment. Misconfigured servers with exposed ports, plaintext secrets, and password-based SSH are an invitation for exactly the kind of attacks the community saw in February 2026.

You have two choices: spend hours hardening a server yourself and commit to ongoing security maintenance, or let a managed platform handle it from day one.

Get started with RunMyClaw. Your OpenClaw installation, secured and running in 60 seconds, for $30/month.