40,000+ Exposed OpenClaw Instances: What Happened and What to Do Right Now

Security researchers at Bitsight have identified 42,665 OpenClaw instances that are directly exposed to the public internet, with no authentication barrier standing between attackers and full remote code execution. The findings, published this week and corroborated by reporting from Infosecurity Magazine and SecurityWeek, represent one of the most significant autonomous-agent security crises of 2026.

If you are running a self-hosted OpenClaw instance, this article is for you. Stop what you are doing and audit your deployment before reading another paragraph.

The Scale of the Problem

Bitsight's internet-wide scan revealed that 63% of all observed OpenClaw deployments are vulnerable. That is not a typo. Nearly two-thirds of every OpenClaw instance researchers could find on the open internet is reachable by anyone with a web browser and a basic understanding of the OpenClaw API.

The 42,665 figure accounts only for instances that responded to active probing. The actual number of exposed deployments is almost certainly higher, as many instances sit behind dynamic IPs or non-standard ports that evade automated scanning.

To put this in perspective: OpenClaw has crossed 180,000 GitHub stars and become the dominant open-source autonomous agent framework in under a year. That explosive adoption has outpaced the community's ability to educate users about basic deployment security, and the results are now plainly visible in Bitsight's data.

How Did 42,000 Instances End Up Exposed?

The root cause is painfully mundane. OpenClaw's default configuration binds its API server to 0.0.0.0, meaning it listens on every network interface, including public-facing ones. Understanding proper agent sandboxing is critical to preventing this. A developer who spins up an instance on a cloud VM and skips firewall configuration has just handed their agent to the entire internet.

Three factors converged to produce this outcome:

Defaults favor convenience over security. Binding to 0.0.0.0 makes local development and Docker container networking simpler. But when developers deploy the same configuration to a VPS or bare-metal server, that convenience becomes a liability.
Documentation does not enforce firewall setup. While the OpenClaw docs mention network security, the guidance is treated as optional rather than a prerequisite. Many users skip it entirely.
Cloud providers vary wildly in default firewall rules. Some providers ship VMs with all ports open unless the user explicitly creates security groups. Others default to restrictive rules. The inconsistency means that an identical docker-compose up command produces a secure deployment on one provider and a fully exposed one on another.

The result: tens of thousands of autonomous AI agents, many connected to production APIs and databases, sitting wide open on the internet.

What Attackers Can Do With an Exposed Instance

An exposed OpenClaw instance is not simply a data leak. It is a fully privileged execution environment. Attackers who reach an unprotected instance can:

Execute arbitrary code. OpenClaw agents run code by design. An attacker can instruct the agent to execute shell commands, install malware, or establish reverse shells. This is remote code execution (RCE) without needing an exploit -- the functionality is a feature of the product.
Exfiltrate data. Any API keys, database credentials, environment variables, or files accessible to the OpenClaw process are immediately available. Agents connected to production systems become a direct path to sensitive data.
Pivot laterally. Once an attacker has code execution on the host machine, they can scan internal networks, exploit trust relationships, and move deeper into the infrastructure. A compromised OpenClaw instance on a corporate network is a beachhead for a full breach.
Abuse connected services. Many OpenClaw deployments connect to external APIs with stored credentials -- email services, payment processors, cloud storage. Attackers inherit access to every service the agent was configured to use.
Install malicious skills. Attackers can load malicious skills into the agent, turning it into a persistent backdoor that survives restarts and operates under the guise of legitimate agent behavior.

The CVE-2026-25253 Compounding Factor

The exposure crisis does not exist in isolation. CVE-2026-25253, a critical remote code execution vulnerability patched in recent OpenClaw releases, means that even instances behind firewalls may be at risk if they have not been updated.

The combination is devastating: exposed instances are trivially exploitable without any CVE, and "secured" instances that skipped the patch are exploitable through the vulnerability. Bitsight's data suggests that a significant number of the 42,665 exposed instances are also running unpatched versions, making them vulnerable through multiple attack vectors simultaneously.

The intersection of default misconfiguration and an unpatched RCE vulnerability creates a threat surface that is orders of magnitude larger than either issue alone.

For a deeper analysis of the CVE and related security issues, see our coverage of OpenClaw security issues in 2026.

What to Do Right Now

If you are running a self-hosted OpenClaw instance, take these steps immediately. Do not wait.

1. Check Your Binding Configuration

Open your OpenClaw configuration file and verify that the server is bound to 127.0.0.1 (localhost) rather than 0.0.0.0. If you need remote access, use a reverse proxy like Nginx or Caddy with proper authentication.

# Dangerous -- listens on all interfaces
host: 0.0.0.0

# Secure -- localhost only
host: 127.0.0.1

2. Audit Your Firewall Rules

Verify that your cloud provider's security groups or your host-level firewall (iptables, ufw, nftables) block inbound traffic to the OpenClaw port. Only allow traffic from known, trusted IP ranges.

# UFW example: deny all, then allow only your IP
sudo ufw deny 8080
sudo ufw allow from YOUR_IP to any port 8080

3. Patch to the Latest Version

Ensure you are running a version of OpenClaw that includes the fix for CVE-2026-25253. Check the OpenClaw releases page for the latest patched version. If you are more than one minor version behind, update immediately.

4. Rotate All Credentials

If your instance was exposed, assume compromise. Rotate every API key, database password, and access token that the OpenClaw process could reach. Check your logs for unusual activity, unexpected API calls, or unfamiliar outbound connections.

5. Audit Installed Skills

Review every skill installed on your instance. The recent discovery of 341 malicious skills in the Claw ecosystem means that even skills you installed intentionally may contain supply-chain compromises. Remove anything you did not explicitly install and verify.

6. Consider Managed Hosting

Self-hosting an autonomous AI agent securely requires continuous vigilance: patching, firewall management, credential rotation, skill auditing, and network monitoring. For teams that cannot dedicate resources to this ongoing burden, managed hosting with built-in security controls eliminates the entire class of misconfiguration vulnerabilities that led to this crisis. Our security page details how KiwiClaw prevents these exposures.

The Broader Lesson

The OpenClaw exposure crisis is not unique to OpenClaw. It is a predictable consequence of shipping powerful developer tools with permissive defaults and relying on documentation to fill the security gap. We saw this pattern with Redis, Elasticsearch, MongoDB, and now autonomous AI agents.

The difference is the stakes. An exposed database leaks data. An exposed autonomous agent executes code, moves laterally, and acts on your behalf. The blast radius of a misconfigured AI agent is categorically larger than that of a misconfigured database.

OpenClaw's maintainers should change the default binding to 127.0.0.1 and require explicit opt-in for network-accessible deployments. Until they do, every new docker run that follows the quickstart guide is a coin flip between a working demo and a public RCE endpoint.

In the meantime, the 42,665 exposed instances identified by Bitsight are not a statistic. They are production systems, personal projects, and corporate deployments that are actively at risk. If you have one, secure it now. If you know someone who does, send them this article.

Need help securing your OpenClaw deployment? KiwiClaw provides fully managed OpenClaw hosting with network isolation, automated patching, and audit logging built in. Get in touch to learn how we can eliminate your exposure risk.