135,000 Exposed OpenClaw Instances: Why Self-Hosting Your AI Agent Is a Liability

Update (2026-02-20): Since this post was published, OpenClaw v2026.1.29 (January 29, 2026) made gateway authentication mandatory and added WebSocket origin validation. The auth: "none" option has been permanently removed. However, the 135,000+ exposed instances identified by SecurityScorecard remain at risk until their operators update. OpenClaw v2026.2.12 patched 40+ additional security vulnerabilities. Self-hosted operators should update immediately.

The numbers are worse than you think

Last week, the SecurityScorecard STRIKE team published research that should alarm anyone running a self-hosted AI agent. Their scan found over 135,000 exposed OpenClaw instances across 82 countries, with the majority concentrated in the United States, Germany, India, the UK, and China.

That number alone is concerning. But the details are far worse: 63% of observed deployments are vulnerable to known exploits, and 12,812 of those instances are directly exploitable via remote code execution. Of the exposed instances examined, 549 were correlated with prior breach activity — meaning the hosts were already compromised before OpenClaw was even installed.

This is not a theoretical risk. These are live, internet-facing servers running AI agents with access to credentials, API keys, communication channels, and in many cases, full shell access to the underlying host.

Why are 135,000 OpenClaw instances exposed?

OpenClaw is powerful open-source software. It gives you an AI agent that can connect to Slack, Discord, email, and dozens of other channels. It can execute code, manage files, and interact with external APIs. That capability is exactly what makes it dangerous when deployed without proper guardrails.

The core problem is that OpenClaw was designed as a local development tool that evolved into something people deploy on servers. The default configuration assumes you are running it on your own machine, behind your own network. When you move it to a cloud VPS, those assumptions break down in several critical ways.

Port exposure

OpenClaw’s gateway listens on port 18789 by default, and the dashboard on port 18790. On a local machine, these are only accessible from localhost. On a cloud server, unless you explicitly configure firewall rules, these ports are accessible to the entire internet. Many hosting providers default their security groups to allow all inbound traffic, and many users never change this.

The SecurityScorecard research found that the majority of exposed instances had these ports wide open. No authentication. No TLS. No firewall. Just a raw gateway endpoint accepting connections from anywhere.

No authentication layer

OpenClaw’s built-in gateway does not require authentication by default. This is a deliberate design choice for local development — you don’t want to authenticate against your own machine. But on a server, this means anyone who can reach the port can interact with your agent, read its conversation history, access its configured channels, and in many cases, execute arbitrary commands.

Credential leakage

When OpenClaw is configured with API keys for AI providers, Slack tokens, Discord bot credentials, or other secrets, those credentials are typically stored in environment variables or configuration files on the filesystem. An exposed instance means an exposed credential store. An attacker who gains access to the gateway can enumerate connected channels, extract API keys, and pivot to other services.

The localhost assumption is broken

Perhaps the most alarming finding in recent weeks is CVE-2026-25253 — covered in depth in our CVE-2026-25253 analysis — which enables one-click remote code execution even on instances bound to localhost. The vulnerability exploits a flaw in how OpenClaw handles certain gateway requests, allowing an attacker to bypass the localhost binding through a crafted request. This means that even users who followed the recommended practice of binding OpenClaw to 127.0.0.1 were still vulnerable.

This CVE fundamentally undermines the “just bind it to localhost” advice that the community has relied on as its primary security measure.

Is the OpenClaw ecosystem secure?

The Register’s coverage in early February characterized the situation bluntly: the OpenClaw ecosystem is still suffering from severe security issues. This is not a single bug or a one-time incident. It is a pattern.

The root cause is a gap between how OpenClaw is built and how it is used. The project’s architecture was designed for single-user, local execution. The community’s demand has pushed it toward multi-user, server-hosted deployments. That transition requires security engineering that most individual users and small teams are not equipped to perform:

• Network hardening — Firewall rules, TLS termination, reverse proxy configuration
• Authentication — Adding an auth layer in front of the gateway and dashboard
• Secrets management — Encrypting credentials at rest, rotating keys, avoiding plaintext storage
• Update management — Patching CVEs promptly across every instance
• Monitoring — Detecting unauthorized access attempts and anomalous behavior
• Isolation — Preventing a compromised agent from accessing the host or other services

Each of these is a non-trivial infrastructure challenge. Together, they represent a full-time operational burden that most users simply skip. For organizations evaluating AI agent deployments, our CISO guide to shadow AI agents covers these risks in depth.

The vibe-coding amplifier

The SecurityScorecard report highlights an additional factor: the rise of “vibe coding” — using AI agents to rapidly generate and deploy applications. OpenClaw is a popular tool in this workflow because it can write, test, and deploy code autonomously.

But vibe coding creates a dangerous feedback loop. Users spin up OpenClaw instances to build apps quickly, and in the rush to ship, security configuration is deferred or forgotten entirely. The instance stays running with default settings. The developer moves on to the next project. The exposed instance remains, quietly waiting to be discovered by the next automated scan.

The 135,000 number is likely an undercount. It reflects only instances that were discoverable through internet-wide scanning. Instances behind NAT, on private networks, or on non-standard ports are not included. The true number of insecurely configured OpenClaw deployments is almost certainly higher.

What the community recommends (and why it’s not enough)

The standard advice for securing a self-hosted OpenClaw instance includes:

1. Bind to localhost only
2. Use a reverse proxy with TLS
3. Add HTTP basic auth or a VPN
4. Keep the software updated
5. Use environment variables for secrets

This is good advice as far as it goes. But CVE-2026-25253 demonstrated that even step one — binding to localhost — is not sufficient when the application itself has vulnerabilities. Steps two and three require configuring Nginx or Caddy, obtaining TLS certificates, and maintaining that infrastructure. Step four requires monitoring for security advisories and redeploying promptly. Step five does not encrypt secrets at rest.

In practice, most self-hosted users do one or two of these things. Very few do all of them. And none of this advice addresses the fundamental issue: an AI agent with shell access and API credentials is a high-value target that demands defense-in-depth, not a checklist.

How Alpha Agent eliminates these risks

Alpha Agent is built on OpenClaw. We use the same core agent runtime, the same channel integrations, and the same skill system. But the infrastructure around it is engineered to eliminate the exact attack surface that the SecurityScorecard report exposed.

Zero inbound ports

Alpha Agent’s EC2 instances have no inbound security group rules. None. There is no SSH, no open port 18789, no dashboard exposed to the internet. All instance management happens through AWS Systems Manager (SSM) Session Manager, which uses outbound-only connections through the SSM agent. There is no port for an attacker to find because there is no port to find.

Isolated Docker containers

Every user gets their own Docker container with strict security controls (see our container isolation architecture for a detailed breakdown):

• Read-only filesystem — The container’s root filesystem is immutable. An attacker cannot modify system binaries, install persistence mechanisms, or tamper with the container image.
• No-new-privileges — The no-new-privileges security option prevents any process from escalating permissions through setuid/setgid binaries.
• Resource limits — Each container is capped at 1.0 CPU and 3072MB of memory, enforced by cgroups. A compromised container cannot starve the host or other users.
• Isolated networks — Each container runs in its own Docker bridge network. There is no inter-container communication. A compromised container cannot reach other users’ workloads.
• tmpfs for temporary files — The /tmp directory is a 256MB tmpfs mount. Temporary files never touch persistent storage.

Nginx subdomain routing

User dashboards are accessible at {slug}.alphaagent.app, routed through an Application Load Balancer to Nginx on the host. Nginx maps subdomains to specific container ports, all bound to 127.0.0.1. Container ports are never exposed outside the host. The gateway is not accessible from the internet at any point in the request path.

KMS encryption for secrets

User secrets — AI provider API keys, channel tokens, OAuth credentials — are encrypted with KMS encryption before storage in DynamoDB. They are decrypted only at container startup and injected via environment files that are not accessible outside the container. Secrets are never stored in plaintext, never committed to configuration files, and never visible through the dashboard API.

Auth0 authentication

Every request to a user’s dashboard passes through Auth0 JWT validation. There is no unauthenticated access to any user-facing endpoint. The management API verifies Stripe subscription status, Auth0 identity, and slug ownership before any operation.

Managed patching

When a CVE like CVE-2026-25253 is disclosed, we patch, rebuild, and redeploy the container image across the fleet. Users do not need to monitor security advisories, download updates, or restart services. The patched version is rolling out while most self-hosted users are still reading the advisory.

The cost of doing it yourself

Running your own OpenClaw instance on a VPS costs roughly $5-20/month for the server, plus the ongoing time investment to keep it secure. That time investment is unbounded. Every new CVE, every infrastructure change, every TLS certificate renewal, every security audit is on you.

Alpha Agent’s Individual plan starts at $19/month. For that, you get a fully isolated container, managed security, automatic updates, S3 workspace backups, and 24/7 uptime — without ever configuring a firewall rule or reading a CVE advisory.

The question is not whether you can self-host OpenClaw securely. Some people can. The question is whether you want securing infrastructure to be a permanent part of your workflow, or whether you want to focus on what the AI agent can actually do for you.

Start secure

If you are running an exposed OpenClaw instance today, the immediate steps are clear: bind to localhost, add a reverse proxy with TLS and authentication, encrypt your secrets, and update to the latest version. Do all of these, not just some.

If you would rather not maintain that stack indefinitely, Alpha Agent exists specifically for this problem. We handle the infrastructure so you can use the agent.

Learn more about our security architecture at alphaagent.app/security, or see our plans at alphaagent.app/pricing.