A month ago, we wrote about OpenClaw's security crisis. At the time, SecurityScorecard had found 42,900 OpenClaw instances exposed to the public internet. We called it a crisis in slow motion.
We were wrong about the slow part.
Penligent's latest analysis, published this week, puts the number at over 220,000 exposed instances. SecurityScorecard's STRIKE team confirmed that 15,200 of those are directly vulnerable to remote code execution. Hunt.io documented active exploitation of CVE-2026-25253, which enables auth token theft from exposed instances.
The exposure isn't just growing. It's accelerating.
How We Got From 42,900 to 220,000
The math isn't complicated. OpenClaw's adoption curve has been vertical — one of the fastest-growing open-source projects in history, passing 100,000 GitHub stars in five days. Every new user who follows a YouTube tutorial, spins up a VPS, and runs the install script without configuring authentication creates another exposed instance.
The tutorials are the problem. Not because they're wrong about installation — most of them get that part right. They're wrong about everything that comes after. Port forwarding, firewall rules, authentication, SSL — the boring stuff that doesn't make for engaging content gets skipped. The result is thousands of OpenClaw instances running with default configurations, bound to 0.0.0.0, accessible to anyone who knows where to look.
And finding them isn't hard. Shodan, Censys, and similar scanning tools index these instances within hours of deployment. Penligent's research documented the exact fingerprints attackers use to identify OpenClaw instances: specific HTTP headers, WebSocket endpoints, and response patterns that make them trivially discoverable.
The CVE Map
The exposure problem is compounded by the vulnerabilities discovered in rapid succession over the past few weeks:
CVE-2026-25253 — One-click remote code execution via malicious link. If your instance is exposed and someone sends you a crafted URL, they can execute arbitrary code on your server. Hunt.io has documented active exploitation in the wild.
ClawJacked — The WebSocket brute-force vulnerability we covered last week. Any website could hijack local OpenClaw instances by connecting to localhost and brute-forcing the password with zero rate limiting. Patched in v2026.2.25, but only helps if you've actually updated.
Malicious ClawHub skills — The Hacker News reported 71 malicious skills actively distributing malware and crypto scams through OpenClaw's official skill marketplace. These aren't theoretical — they're live.
Malicious npm package — Pago Networks discovered a supply chain attack: a fake npm package impersonating the OpenClaw installer, targeting first-time users during setup.
Each of these is bad on its own. Together, they paint a picture of an ecosystem where the attack surface is expanding faster than defenses can keep up.
What "Exposed" Actually Means
There's an important distinction that gets lost in the headlines. "Exposed to the internet" doesn't automatically mean "compromised." It means the instance is reachable from the public internet — which means it's one vulnerability away from compromise at any given moment.
Of Penligent's 220,000+ exposed instances:
- 15,200 are confirmed vulnerable to remote code execution (SecurityScorecard STRIKE team)
- An unknown but significant number are running unpatched versions susceptible to ClawJacked
- Many are running with default credentials or weak passwords that can be brute-forced
- Most have no reverse proxy, no SSL, and no authentication layer in front of the OpenClaw gateway
The practical impact depends on what each instance has access to. For a hobbyist running a toy setup with no connected services, exposure is embarrassing but not catastrophic. For a developer who connected their OpenClaw agent to Slack, GitHub, email, and cloud infrastructure — which is exactly what the popular tutorials encourage — exposure means potential access to everything the agent can reach.
The Deployment Problem
Here's what frustrates me about this situation: the exposure is almost entirely preventable.
Every single one of those 220,000 instances could be secured with basic infrastructure practices — a reverse proxy with authentication, a firewall restricting inbound access, SSL termination, and regular updates. This isn't exotic security knowledge. It's the same stuff you'd do for any internet-facing service.
But the people deploying OpenClaw aren't infrastructure engineers. They're developers, business owners, and enthusiasts who watched a YouTube tutorial and followed the steps. The tutorial said "run this script" and they ran it. It didn't say "now spend two hours configuring nginx, certbot, and ufw" because that's boring and it doesn't get clicks.
The OpenClaw project itself shares some blame. The default configuration binds to all interfaces (0.0.0.0) rather than localhost. The documentation buries security guidance deep in pages that most users never read. The install script prioritizes getting the agent running quickly over getting it running safely. That's a reasonable tradeoff for a development tool — but OpenClaw stopped being a development tool months ago. It's infrastructure now, and it needs to act like it.
What Needs to Change
For the OpenClaw project: defaults need to be secure by default. Bind to localhost unless explicitly configured otherwise. Require authentication during initial setup, not as an optional post-install step. Show a warning if the instance is publicly accessible. These aren't feature requests — they're table stakes for software that handles credentials and executes commands.
For users with exposed instances: you need to act this week, not eventually. Here's the minimum:
- Check if you're exposed. Search for your server's IP on Shodan or Censys. Or use our free Security Exposure Checker.
- Restrict access immediately. Configure your firewall to block inbound traffic to the OpenClaw port from the public internet. If you need remote access, put it behind a VPN or SSH tunnel.
- Update to the latest version. The ClawJacked patch and other security fixes are in v2026.2.25+.
- Rotate all credentials. If your instance was exposed, assume any API keys, tokens, and passwords the agent had access to are compromised. Rotate everything.
- Put a reverse proxy in front of it. Nginx or Caddy with proper authentication and SSL. This should have been step one.
For everyone else: don't add to the count. If you're deploying OpenClaw, do it on isolated infrastructure with security built in from the start. Not bolted on after.
The Trajectory
In January, Censys found 21,639 exposed instances. In early February, SecurityScorecard found 42,900. Now Penligent counts 220,000+. That's a 10x increase in two months, and adoption is still accelerating.
We've been writing about OpenClaw security since December, and every article ages poorly within weeks because the numbers keep getting worse. The community is growing faster than its security maturity, and that gap is widening.
At some point, the exposure reaches a threshold where organized attackers build automated tooling specifically for compromising OpenClaw instances at scale. Given the value of what these agents can access — API keys, cloud credentials, private messages, business data — that threshold may have already been crossed.
The 220,000 number isn't the ceiling. It's where we are today.
Check if your instance is exposed: Use the free OpenClaw Security Exposure Checker to find out in seconds — no sign-up required.
Don't become one of the 220,000. Clawdy deploys OpenClaw on isolated infrastructure with authentication, SSL, and firewall rules configured from the start — in under 60 seconds. Get started at clawdy.app.