135,000 OpenClaw Instances Are Exposed to the Internet. Here’s Why Professional Setup Matters.

OpenClaw is one of the most powerful open-source tools released in recent years. It’s also one of the most dangerous when misconfigured.

In the weeks following its viral adoption in early 2026, security researchers from Microsoft, Cisco, Kaspersky, CrowdStrike, and Trend Micro published detailed analyses of OpenClaw’s security posture. The findings were consistent and alarming: the vast majority of OpenClaw deployments are running with critical security gaps that leave them vulnerable to remote exploitation, data exfiltration, and complete system compromise.

The vulnerabilities documented in these studies aren’t theoretical concerns. They’re happening at scale, right now.

The numbers

Multiple independent scanning teams have documented the scope of the problem. SecurityScorecard’s STRIKE team found 135,000+ exposed instances across 82 countries, with 15,200 directly vulnerable to remote code execution. Bitsight independently flagged 63% of observed deployments as vulnerable. 98.6% of exposed instances run on cloud infrastructure, meaning these are businesses, not hobbyists.

549 exposed instances were already correlated with prior breach activity. Palo Alto Networks called OpenClaw “the potential biggest insider threat of 2026.”

These exposed and vulnerable instances aren’t edge cases. They represent the norm for how OpenClaw gets deployed.

Why the defaults are dangerous

OpenClaw ships with several default settings that security researchers have flagged as inappropriate for any production deployment.

OpenClaw binds to 0.0.0.0:18789 by default, exposing every network interface, including the public internet. It should bind to 127.0.0.1. It does not. Authentication is disabled by default. When you spin up a new instance, the gateway is immediately accessible without any credentials. Anyone who can reach the port can interact with your agent, your data, and your connected services.

Credentials are stored in plaintext. API keys, OAuth tokens, and bot credentials for every connected service sit in unencrypted configuration files. Microsoft’s Defender team noted that versions of the RedLine and Lumma infostealers have already added OpenClaw file paths to their targeted steal lists.

The gateway broadcasts configuration via mDNS. Simply starting an instance can advertise its presence on the local network.

Microsoft’s security team put it directly: “OpenClaw should be treated as untrusted code execution with persistent credentials. It is not appropriate to run on a standard personal or enterprise workstation.”

The critical vulnerabilities

Beyond configuration issues, OpenClaw has faced several severe vulnerabilities since its launch.

CVE-2026-25253, rated CVSS 8.8, enabled one-click remote code execution through a browser-based attack. A single researcher discovered it in 1 hour 40 minutes of analysis. If the OpenClaw agent visited a webpage containing malicious JavaScript, or if a user clicked a malicious link, the gateway authentication token would leak, giving the attacker full administrative control in milliseconds. No prior access required.

This vulnerability was patched in version 2026.1.29, but the patch was initially incomplete. A Docker sandbox bypass (CVE-2026-24763) was quickly discovered, requiring an additional fix in version 2026.1.30. Two additional command injection vulnerabilities were also addressed.

Version 2026.2.12 fixed 40+ vulnerabilities in a single release. Any OpenClaw instance running an older version is exposed to all of them.

The supply chain problem

The ClawHub skills marketplace (OpenClaw’s ecosystem for extending functionality) has been a persistent security concern. Koi Security and Bitdefender found 820+ malicious skills in ClawHub, representing 20% of the entire registry. Cisco’s Talos team confirmed the scope, primarily delivering the Atomic macOS Stealer (AMOS).

The project has since partnered with VirusTotal to scan all uploads, but the damage to early adopters was already done. For business deployments, every skill should be audited before installation, and only verified, reviewed components should be allowed.

What proper security hardening looks like

A production-grade OpenClaw deployment requires attention to several layers.

Network isolation. The gateway should never be directly exposed to the public internet. Access should be mediated through a VPN (Tailscale is commonly recommended), SSH tunnel, or properly configured reverse proxy with TLS termination and authentication.

Authentication enforcement. Gateway authentication must be enabled immediately after installation. Default tokens should be rotated. Pairing codes should be time-limited.

Credential management. API keys and tokens should be moved out of plaintext configuration files where possible. At minimum, file permissions on the configuration directory should be locked down to prevent unauthorized access.

Container isolation. Docker sandboxing should be enabled for skill execution, with strict resource limits and no host network access.

Permission scoping. The agent should operate with the minimum permissions necessary for its intended tasks. Full system access should never be the default.

Monitoring and audit logging. All agent actions should be logged. Anomalous behavior, such as unexpected file access, unusual API calls, or new network connections, should trigger alerts.

Regular updates. OpenClaw is under active development. Security patches ship frequently. Running an outdated version is one of the most common risk factors.

What this means for businesses

The pattern with OpenClaw is clear: the tool is extraordinarily powerful, but it ships configured for convenience, not security. The responsibility for hardening falls entirely on the person deploying it.

For individual developers experimenting on personal machines, this risk calculus may be acceptable. For businesses running OpenClaw against production data, customer information, financial systems, or operational infrastructure, the stakes are fundamentally different.

A misconfigured deployment isn’t just an inconvenience. It’s a potential pathway to data breach, credential theft, and system compromise, and given the documented activity of infostealers and malicious skills already targeting OpenClaw, these aren’t theoretical risks.

The case for professional deployment

CrowdStrike noted that if employees deploy OpenClaw on corporate machines and leave it misconfigured, it can be turned into an AI backdoor capable of taking instructions from adversaries. Gartner characterized OpenClaw as “a dangerous preview of agentic AI, demonstrating high utility but exposing enterprises to insecure-by-default risks.”

This is precisely why professional installation matters. The security hardening required for a production OpenClaw deployment goes far beyond following the official documentation. It requires understanding network architecture, credential management, container isolation, permission models, and the specific ways OpenClaw’s design decisions create attack surface.

The difference between a properly secured OpenClaw installation and a default one is the difference between a powerful business tool and a liability.