Aerostack
Aerostack

42,000 OpenClaw Instances Are Exposed Right Now. Is Yours One of Them?

Bitsight found 42K exposed OpenClaw instances. Kaspersky confirmed malware targeting them. 6 CVEs in 2026. Here's what you should do right now.

Navin Sharma

Navin Sharma

@navinsharmacse

May 16, 20266 min read
42,000 OpenClaw Instances Are Exposed Right Now. Is Yours One of Them?

Last month, Bitsight security researchers published data on the state of OpenClaw deployments across the public internet. The number they found stopped me mid-coffee: 42,000+ instances running on public IPs with no authentication layer. Most had default settings. Nearly all exposed an API endpoint you could hit from anywhere. No gateway token. No firewall rules. Just... open.

I've been building agent infrastructure for two years. I know the OpenClaw ecosystem well enough to know why this happened. And it's scarier than the number alone suggests.

Six CVEs in 2026. None of them patched on most instances.

Cisco published a report calling OpenClaw-based personal AI agents "a security nightmare." That's not hyperbole when you look at the vulnerability timeline this year:

  • CVE-2026-25253 (CVSS 8.8): One-click RCE via malicious skill upload. No validation on skill code execution.

  • CVE-2026-24891 (CVSS 7.6): Plaintext credential storage in config files. Readable by any process on the host.

  • CVE-2026-24102 (CVSS 7.2): MCP server path traversal. An OpenClaw instance with write access to your file system can escape sandbox.

  • Three more in the 6.8–7.1 range.

Kaspersky's threat intelligence team found RedLine and Lumma stealer malware actively probing for OpenClaw instances. They're looking for /skill and /gateway endpoints specifically. When they find them, they deploy credential-stealing skills. This isn't theoretical.

824 malicious skills on ClawHub in one quarter

1Password security researchers did a 30-day sweep of ClawHub (OpenClaw's community skill marketplace) and flagged 824 skills with malicious patterns:

  • Credential stealers extracting from browser storage

  • Reverse shells opening SSH tunnels back to attacker infrastructure

  • Keyloggers on every keystroke

  • Data exfiltration to Telegram channels

Most had been up for weeks before removal. Some had 100+ installs.

The scary part? A lot of these got through because OpenClaw's skill review process is community-driven, not automated. The marketplace trusts the community to flag bad code. When the community is quiet, bad code lives.

Gartner's assessment: "insecure by default"

A few weeks ago, Gartner published their take on personal AI infrastructure. Direct quote: "OpenClaw and similar platforms are insecure by default. Plaintext credential storage, no built-in RBAC, and permission models designed for single-user scenarios are fundamentally mismatched to production agent workloads."

They're not wrong. If you're running OpenClaw in production today—and 42,000 people are—you're probably doing one of these things:

  1. Storing API keys in plain JSON config files

  2. Running on a machine with other services (browser, email, IDE)

  3. Assuming your firewall is good enough

  4. Hoping no one finds your instance

None of those are security strategies.

Microsoft, Cisco, Meta all published warnings

In the last 8 weeks:

  • Microsoft issued guidance: "Do not use OpenClaw for production workloads without implementing separate authentication and authorization layers."

  • Cisco recommends: "Run OpenClaw in isolated containers. Segment network access. Audit skill uploads manually."

  • Meta banned OpenClaw instances from accessing their OAuth endpoint, citing "insufficient security guarantees."

These aren't suggestions. They're companies protecting their users from the fallout of an insecure deployment.

What the community figured out (the hard way)

I follow the OpenClaw Discord. There's a subset of people who've been running instances in production for months. They've learned what works:

  • Gateway tokens: Enable auth on your instance endpoint. Don't expose it naked.

  • Firewall rules: Lock down which IPs can talk to your instance.

  • Separate instances: One for read-only MCP servers. One for write operations. Never run them together.

  • TOTP MFA: tugcantopaloglu built a dashboard patch that adds two-factor auth. Not official, but it works.

  • Audit skills: Before installing anything, read the code. Yes, actually read it.

These people are running safely. They also spent weeks learning this the hard way. Most teams don't have that luxury.

What we did differently at Aerostack

Full disclosure: I'm the founder of Aerostack. We built a different model.

Instead of exposing MCP servers directly to agents, we put a permission layer in between—the Workspace. Every tool gets explicit allow/deny rules. If an agent tries to call a tool that isn't in its allowed list, the request doesn't go through. Period.

Raw OpenClaw vs. Aerostack — unrestricted MCP access vs. permission-controlled workspace

We also don't store credentials in config files. Secrets go into Aerostack's encrypted vault (AES-256). The agent connects to the workspace with a revocable token — it never sees the raw API keys. If someone compromises the machine, they get a token that can be killed in seconds, not your actual credentials.

Does that mean we're perfect? No. But it means the surface area for attack is smaller. And that matters.

(Worth noting: we're not the only team thinking about this differently. Anthropic, Hugging Face, and others are building agent security layers. The industry is waking up to the fact that "just run the code" isn't a deployment strategy.)

The practical advice (whether you use Aerostack or not)

If you're running OpenClaw right now, here's what I'd do today:

  1. Enable gateway authentication. Do not expose your instance without a token.

  2. Firewall your instance. Restrict which IPs can reach it. If you're running locally, bind to 127.0.0.1 only.

  3. Audit your skills. Go through everything you've installed. If you can't read the code, uninstall it.

  4. Separate your MCP configs. Keep read-only servers in one config. Write operations in another.

  5. Monitor for unusual activity. If your instance is suddenly making API calls you didn't ask for, that's a sign.

  6. Don't assume your firewall is enough. Firewalls get misconfigured. Explicitly lock down OpenClaw.

If you're not running OpenClaw yet, and you're thinking about it: that's fine. Just start with security first, not as an afterthought. The first thing you configure should be auth, not "let me spin this up quick."

The bigger picture

42,000 exposed instances tells me the industry is treating agent infrastructure like it's still 2025. We built it fast. We prioritized capability over safety. Now we're paying for it.

The CVEs will get patched. The malicious skills will get removed. But the underlying problem — that OpenClaw wasn't designed for threat models where anything that can reach your instance is potentially adversarial — that problem is structural. You can patch it with gateway tokens and firewalls. But you can't design it away retroactively.

That's the gap we're building Aerostack to fill. Not because we're more cautious. But because we saw the data and decided to build security into the foundation, not bolt it on after the breach.

If you're building agent infrastructure, learn from that data. Don't be one of the 42,000.

Start here: aerostack.dev


Part of the Agent Operations series. Start with the full guide: "I Run 5 MCP Servers on OpenClaw"