In January 2026, security researcher Lena Park published a scan of the public internet looking for exposed OpenClaw instances. She found 42,317 of them. Accessible to anyone. Many with no authentication at all.
That number has probably grown since then.
If you're self-hosting OpenClaw, there's a real chance your instance is one of them. Not because you're careless, but because the default installation doesn't force you to be secure. And the documentation buries the security configuration behind 15 other setup steps that feel more urgent.
Let's walk through the most common mistakes, what an attacker could do with each one, and how to fix them.
Mistake 1: Running on default ports without a firewall
OpenClaw's gateway runs on port 18789 by default. When you install it on a VPS, that port is often open to the internet unless you specifically configure a firewall to block it.
What this means: Anyone who scans your server's IP address (and people scan the entire internet continuously) can find your OpenClaw instance. Automated scanners specifically look for port 18789 now because they know what's behind it.
What an attacker could do: If the port is open and there's no authentication (see Mistake 2), they have full access to your assistant. That means access to everything your assistant is connected to: your email, your calendar, your files, your messaging accounts. They can read your email. They can send emails as you. They can access any API keys stored in the configuration.
How to fix it: Set up a firewall. On Ubuntu/Debian:
sudo ufw default deny incoming
sudo ufw allow ssh
sudo ufw enable
Then only expose OpenClaw through a reverse proxy with authentication, or use a VPN like Tailscale so it's only accessible from your devices. Never expose port 18789 directly to the internet.
Mistake 2: No authentication on the gateway
OpenClaw's gateway can be configured to require a token for access. But it doesn't require one by default. If you skip this step during setup (and many guides don't emphasize it), anyone who finds your instance can interact with it freely.
What an attacker could do: Everything. Full control of your assistant. Send messages, trigger automations, read connected account data, exfiltrate API keys. This is the skeleton key.
How to fix it: Set a gateway token in your OpenClaw configuration. This is a password that must be included with every request to the gateway. Without it, requests are rejected. It takes 30 seconds to configure and it's the single most important security step.
In your openclaw.json:
{
"gateway": {
"token": "a-long-random-string-here"
}
}
Generate a strong token: openssl rand -hex 32
Mistake 3: API keys in plain text
Your OpenClaw configuration includes API keys for AI providers (OpenAI, Anthropic), email credentials, and tokens for connected services. In a default installation, these are stored in plain text in configuration files on the server.
What an attacker could do: Steal your API keys and run up massive bills. OpenAI API abuse can cost thousands of dollars in hours. Steal your email credentials and access your email directly, bypassing your assistant entirely. Use your connected service tokens to access your calendar, cloud storage, or anything else you've connected.
How to fix it: At minimum, ensure your configuration files have restrictive permissions (chmod 600). Better yet, use a secrets manager or environment variables for sensitive values. And never, ever commit API keys to a Git repository (yes, people do this).
Mistake 4: Running as root
Many installation guides have you SSH in as root and install OpenClaw directly. The assistant then runs with root privileges on the server.
What an attacker could do: If they find any vulnerability in OpenClaw (and software always has vulnerabilities), they don't just get access to OpenClaw. They get root access to the entire server. They can install malware, create backdoor accounts, use your server to attack other systems, or destroy everything.
How to fix it: Create a dedicated non-root user for OpenClaw:
sudo adduser openclaw --disabled-password
Run OpenClaw as that user. Give it only the permissions it needs and nothing more. This limits the blast radius if something goes wrong.
Mistake 5: No SSL/TLS encryption
If you access your OpenClaw instance over plain HTTP (not HTTPS), everything between your device and the server is unencrypted. Your messages, your gateway token, your data, all of it travels across the internet in plain text.
What an attacker could do: Anyone on the same network (coffee shop WiFi, hotel, airport) can see everything you send to and receive from your assistant. Including your authentication token, which they can then use to access your instance from anywhere.
How to fix it: Set up HTTPS. If you're using a domain, Let's Encrypt provides free SSL certificates. If you're using Tailscale or another VPN, the traffic is encrypted by the VPN tunnel, so this is less critical (but still good practice).
Mistake 6: Never updating
OpenClaw releases security patches regularly. The February 2026 ClawHavoc incident resulted in critical patches (CVE-2026-25253 and CVE-2026-26329) that fixed skill sandbox escapes and authentication bypasses.
If you installed OpenClaw three months ago and haven't updated since, you're running software with known vulnerabilities. Vulnerabilities that have been publicly documented, complete with instructions on how to exploit them.
What an attacker could do: Exploit known vulnerabilities to bypass authentication, escape skill sandboxes, access the host filesystem, or take full control of your instance. These aren't theoretical, they're documented and actively exploited.
How to fix it: Check your version: openclaw --version. Compare it to the latest release. Update regularly. Set a reminder if you have to. Once a month at minimum, preferably whenever a security advisory is published.
Mistake 7: Installing unvetted ClawHub skills
This one's fresh. The ClawHavoc supply chain attack in February 2026 found 386 malicious skills on ClawHub. Skills that looked legitimate but exfiltrated user data to external servers.
What an attacker could do: If you've installed skills from ClawHub without carefully reviewing their code, they could be sending your emails, API keys, calendar data, and files to an attacker's server right now. Some of the malicious skills also installed persistent backdoors that survive skill removal.
How to fix it: Audit your installed skills. Remove any you didn't personally verify. Stick to OpenClaw's built-in skills. If you must use third-party skills, review the source code before installing. Or use a managed provider that doesn't allow third-party skills at all.
The security checklist
If you're self-hosting, go through this list right now:
- Firewall active with only necessary ports open (SSH + your reverse proxy)
- Gateway token set (long, random, unique)
- Not running as root (dedicated user with limited permissions)
- HTTPS enabled or accessing exclusively through a VPN
- Configuration files have restrictive permissions (600 or 640)
- API keys are not in any Git repository
- OpenClaw is up to date (check against latest release)
- No unvetted ClawHub skills installed
- SSH key authentication enabled (password authentication disabled)
- Automatic security updates enabled for the operating system
- Regular backups configured and tested
If you can't check every box on this list, your instance is at risk. That's not a scare tactic. It's just reality. Each unchecked item is a door that someone, somewhere, is trying to open.
Why this keeps happening
The OpenClaw team ships great software. The security features exist. The problem is the gap between "features exist" and "users enable them."
Most people installing OpenClaw are following a tutorial they found on YouTube or a blog post. They want a working assistant, not a security detailed look. So they skip the firewall step because it's "optional." They skip the gateway token because they want to test it quickly. They run as root because that's what the tutorial shows.
Every shortcut makes sense in the moment. The result is 42,000+ exposed instances.
How to check if YOUR instance is exposed
Before you assume you're fine, check. It takes 5 minutes.
Step 1: Check your firewall status. SSH into your server and run:
sudo ufw status
If it says "inactive," your firewall isn't running. Everything is exposed.
Step 2: Scan your own ports from outside.
From a different computer (not the server), visit a port scanner like nmap.online or use nmap if you have it:
nmap -p 18789 YOUR_SERVER_IP
If port 18789 shows as "open," your OpenClaw gateway is directly accessible from the internet.
Step 3: Try accessing it without a token.
Open a browser and go to http://YOUR_SERVER_IP:18789. If you see a response (even an error page), the port is exposed. If the page loads with actual OpenClaw content, you have no authentication.
Step 4: Check your OpenClaw version.
openclaw --version
Compare this against the latest release at the OpenClaw GitHub releases page. If you're more than one minor version behind, update immediately.
Step 5: Check your running user.
whoami
If it says "root," you're running as root. Fix this.
If any of these checks reveal a problem, stop what you're doing and fix it now. Not tomorrow. Not this weekend. Right now. The 42,000+ exposed instances were all "I'll fix it later" situations.
Real-world impact: what actually happens when you get compromised
This isn't hypothetical. Here are real scenarios from the OpenClaw subreddit and security forums (anonymized):
The API key drain. A user's exposed instance had their OpenAI API key stolen. The attacker used it to run a prompt injection service, burning through $4,200 in API credits over a weekend. OpenAI doesn't refund stolen key usage.
The email takeover. An exposed instance with Gmail credentials was used to send phishing emails from the owner's account. Their email domain got blacklisted, affecting their entire business email. Cleaning up took three weeks and involved contacting every client to explain the situation.
The silent watcher. One of the most unsettling cases: a user discovered their exposed instance had been accessed by someone who never changed anything. They just read. For two months. Every email summary, every calendar entry, every research query. The user only found out during a routine check of their access logs.
The crypto miner. An instance running as root was compromised, and the attacker installed cryptocurrency mining software. The user's VPS bill went from $5/month to $800/month before their hosting provider flagged the abnormal usage and suspended the account.
These aren't edge cases. They're the natural consequences of running internet-facing software without proper security. Each one of them was preventable with basic security hygiene.
The cost of "free" security
Self-hosting OpenClaw is cheap. Securing it properly takes knowledge and ongoing attention. Here's what good security actually requires:
Initial setup: 2-4 hours to properly configure firewall rules, create a non-root user, set up a reverse proxy with SSL, configure authentication, and lock down SSH. This assumes you know what all of those things are and how to do them.
Ongoing maintenance: 30-60 minutes per month to apply updates, review access logs, check for configuration drift, and verify that everything is still locked down. Security isn't a one-time thing. It's continuous.
Incident response: If something goes wrong (and with 42,000 targets, someone's getting hit daily), the time to investigate, remediate, and recover can be days to weeks. Do you have a plan for that? Do you know how to check if someone accessed your email through a compromised OpenClaw instance?
Knowledge investment: Understanding security well enough to do it right requires learning. A lot of it. Firewall rules, SSL/TLS configuration, log analysis, threat modeling. Most people don't have this knowledge and don't want to acquire it.
Add up the hours. Multiply by what your time is worth. The "free" security of self-hosting is often more expensive than paying $29/month for someone to handle it.
The alternative: let someone else worry about it
Self-hosting gives you control. It also gives you responsibility. If security configuration isn't something you're comfortable with (or interested in), a managed OpenClaw host handles all of this for you.
Every item on that checklist above? It's someone else's job. Firewalls, authentication, encryption, updates, skill vetting, access controls. All handled by a team whose full-time job is keeping your instance secure.
Or skip the security headache entirely. KillerBot handles all of this for $29/month. Your instance is isolated, encrypted, automatically updated, and we don't run any third-party ClawHub skills. You focus on using the assistant. We focus on keeping it safe.
If you do self-host (and it's a valid choice), please go through that checklist. Your email, your calendar, your API keys, and your data are worth the 30 minutes it takes to secure them properly.