40,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.

This isn’t a theoretical concern. It’s happening at scale, right now.

The numbers

Multiple independent scanning teams have documented the scope of the problem. Censys tracked growth from roughly 1,000 to over 21,000 publicly exposed OpenClaw instances in a single week in January 2026. Bitsight observed more than 30,000 instances. Security researcher Maor Dayan independently verified over 42,000 exposed instances, of which more than 5,000 were actively confirmed vulnerable — with 93% exhibiting authentication bypass conditions.

SecurityScorecard’s STRIKE team found over 135,000 exposed instances across 82 countries, with more than 15,000 directly vulnerable to remote code execution.

These 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.

Authentication is disabled by default. When you spin up a new OpenClaw 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 remote code execution through a browser-based attack. 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.

Any OpenClaw instance running a version older than 2026.1.30 should be considered compromised.

The supply chain problem

The ClawHub skills marketplace — OpenClaw’s ecosystem for extending functionality — has been a persistent security concern. Cisco’s Talos team found that 12% of the entire skills registry contained malicious code, primarily delivering the Atomic macOS Stealer (AMOS). Updated scans later reported the figure at roughly 20%, or over 800 malicious skills.

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 — unexpected file access, unusual API calls, 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.