What Actually Happens When You Expose OpenClaw to the Internet

You found OpenClaw. You spun up a VPS, ran the install script, and had an AI agent running in under an hour. It felt great.

What you probably did not notice is that your instance was listening on every network interface, with its WebSocket port wide open to the public internet. No firewall rule. No reverse proxy. No authentication gate between the outside world and your agent's control plane.

You are not alone. As of early 2026, that is the default experience for the majority of OpenClaw operators.

The numbers are not abstract

Bitdefender's February 2026 report identified over 135,000 internet-facing OpenClaw instances. That number is not a projection or a worst-case model. It is a count of real, reachable endpoints that respond to connection attempts on the default port.

"Security researchers identified more than 135,000 internet-facing OpenClaw instances... OpenClaw binds by default to 0.0.0.0:18789, meaning it listens on all interfaces unless an operator explicitly restricts it."

The 0.0.0.0 binding is the critical detail. On a typical VPS, that means your OpenClaw control port is accessible to anyone who scans the IP range your provider uses. And people scan constantly.

What an attacker actually sees

When your OpenClaw instance is exposed, someone connecting to it gets access to the Gateway WebSocket. From there, depending on your configuration, they can potentially:

• Read your agent's conversation history and context, including anything your agent has processed
• Inject prompts and instructions into active agent sessions
• Access any tools or integrations your agent is connected to, including file system access, API keys, and external services
• Exfiltrate stored credentials if your agent handles secrets in its workflow

This is not theoretical. The GitHub Security Advisory GHSA-g8p2-7wf7-98mq documented a chain where the Control UI trusts a gatewayUrl from the query string without validation and auto-connects on load, sending the stored gateway token to whatever endpoint is specified. That means even instances configured for loopback-only access were vulnerable to token exfiltration through a crafted URL.

"This vulnerability is exploitable even on instances configured to listen on loopback only..."

Why the defaults create this problem

OpenClaw's architecture is designed for flexibility. That is a genuine strength for experienced operators who know exactly how they want to configure networking, authentication, and access control.

But flexibility without safe defaults means every new operator starts in an insecure state and has to actively work their way toward a secure one. The official docs acknowledge this directly:

"There is no 'perfectly secure' setup. Start with the smallest access that still works..."

That is honest and responsible documentation. The problem is that most people deploying OpenClaw for the first time are not reading the security docs carefully. They are following a quickstart guide, and the quickstart gets them running before it gets them secure.

The common deployment pattern

Here is what a typical first deployment looks like:

1. Rent a VPS from Hetzner, DigitalOcean, or Linode
2. SSH in and run the OpenClaw install script
3. Access the web UI on port 18789 -- it works immediately
4. Start building agents and connecting tools
5. Never revisit the network configuration

At step 3, the instance is already exposed. There is no warning, no prompt to configure a firewall, no mandatory auth setup before the UI loads. The operator sees a working interface and assumes things are fine.

Weeks or months later, if they check at all, they discover their instance has been reachable the entire time.

The Clawctl findings

Independent security researchers at Clawctl documented 42,665 exposed OpenClaw instances in a separate scan, confirming the pattern at scale. Their report highlights a recurring issue with reverse proxy and localhost trust configurations:

Reverse proxy + localhost trust mistakes are a recurring path to unauthenticated access.

This means even operators who took the extra step of adding a reverse proxy sometimes configured it in a way that preserved the underlying vulnerability rather than fixing it.

What this means for you

If you are running OpenClaw on a VPS right now, there is a reasonable chance your instance is exposed unless you have specifically:

• Changed the bind address from 0.0.0.0 to 127.0.0.1
• Configured a reverse proxy with proper authentication
• Set up firewall rules to block external access to the default port
• Verified your configuration with an external port scan

If you have not done all four of those things, your instance is likely reachable.

This is not about blame. The defaults are what they are, and most developers are focused on building agents, not hardening network configurations. But the exposure is real, and understanding it is the first step toward fixing it.

References

• Bitdefender, "135,000+ OpenClaw AI agents exposed online": bitdefender.com
• GitHub Security Advisory GHSA-g8p2-7wf7-98mq: github.com
• Clawctl report, "42,665 Exposed OpenClaw Instances": clawctl.com
• OpenClaw docs, "Security": docs.openclaw.ai