The 30,000 Exposed OpenClaw Instances Problem — And How to Avoid Being One of Them

How Did 30,000 OpenClaw Instances End Up Exposed on the Public Internet?

Censys published scan results in March 2026 showing over 30,000 OpenClaw instances reachable from the open internet with default configurations. No authentication. No firewall rules. Default ports wide open. That number has likely grown since the scan was completed.

The root cause is painfully simple: OpenClaw’s default configuration is designed for local development, not production. When someone deploys it on a cloud VPS or a machine with a public IP address, every service binds to 0.0.0.0 by default — meaning it accepts connections from anywhere. The gateway, the agent runtime, the management API — all of it, publicly reachable.

Shadowserver Foundation tracked a 340% increase in scanning activity targeting OpenClaw’s default ports (3000 and 8080) between January and March 2026. Attackers aren’t guessing. They’re running automated sweeps and finding thousands of unprotected targets.

What Is CVE-2026-25253 and Why Is It Critical?

CVE-2026-25253 is a remote code execution vulnerability in OpenClaw’s gateway component. It carries a CVSS score of 9.8 — critical severity. The attack requires no authentication, no user interaction, and no special privileges. If your gateway is reachable and running without auth, you’re vulnerable.

Here’s what happens: the OpenClaw gateway accepts agent execution requests over HTTP. In default mode, there’s no authentication check. An attacker sends a crafted payload to the /api/v1/execute endpoint that injects system commands into the agent’s execution context. Because the default Docker configuration mounts the host’s Docker socket into the container, the attacker can escape the container entirely and execute commands on the host system.

MITRE assigned this CVE on March 12, 2026. The OpenClaw security team issued a patch within 48 hours, but patching alone doesn’t fix the core problem — the default configuration is still insecure. CISA added CVE-2026-25253 to the Known Exploited Vulnerabilities catalog on March 18, meaning federal agencies have mandatory remediation timelines.

Palo Alto Networks’ Unit 42 confirmed active exploitation in the wild within five days of public disclosure. The exploit requires roughly 15 lines of Python. We’re not talking about a sophisticated nation-state attack — this is script-kiddie accessible.

What Does a Vulnerable OpenClaw Configuration Actually Look Like?

Let’s walk through the three default configuration failures that make exploitation possible. If you’re running OpenClaw, check these right now.

Is Your Gateway Running Without Authentication?

The default docker-compose.yml that ships with OpenClaw looks something like this:

# VULNERABLE: default config — no auth on gateway
services:
  gateway:
    image: openclaw/gateway:latest
    ports:
      - "3000:3000"
    environment:
      - AUTH_ENABLED=false
      - GATEWAY_HOST=0.0.0.0

Two problems jump out immediately. AUTH_ENABLED=false means anyone who can reach port 3000 can send execution requests. GATEWAY_HOST=0.0.0.0 binds the service to all network interfaces, including your public IP.

According to the OWASP Top 10 for AI Applications (2025 edition), “Missing Authentication for AI Agent Interfaces” is the number-two risk on the list. OpenClaw’s own documentation includes a security notice about this — but it’s in a section most people skip during initial setup.

Is Your Docker Socket Mounted Into the Container?

This is the configuration that turns a container escape from theoretical to trivial:

# VULNERABLE: Docker socket exposed to agent container
services:
  agent:
    image: openclaw/agent:latest
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

Mounting /var/run/docker.sock gives the container full control over the Docker daemon on the host. The agent can create new containers, execute commands on the host, read any file on the system, and even install rootkits. NIST SP 800-190 (Application Container Security Guide) explicitly calls this out: “Do not mount the Docker socket inside containers unless absolutely necessary, and never in production environments.”

The OpenClaw documentation includes the socket mount for convenience — it enables certain plugin features during development. But in production, it’s equivalent to handing root access to anything running inside the container — see why AI agents should be treated as privileged accounts.

Are Your Services Binding to 0.0.0.0?

Even if you’ve enabled authentication on the gateway, binding internal services to 0.0.0.0 can expose the management API, metrics endpoints, and internal agent communication channels. The Censys scan found that 68% of the exposed instances had at least three services reachable on public interfaces that were meant to be internal-only.

Datadog’s 2026 Container Security Report found that binding to 0.0.0.0 was the single most common misconfiguration in containerized deployments — present in 41% of production Docker Compose files they analyzed across 8,000 organizations.

What Does a Hardened OpenClaw Configuration Look Like?

Here’s what the same deployment looks like after proper hardening:

# HARDENED: production-ready OpenClaw config
services:
  gateway:
    image: openclaw/gateway:latest
    ports:
      - "127.0.0.1:3000:3000"
    environment:
      - AUTH_ENABLED=true
      - AUTH_TOKEN_SECRET=your-generated-secret-here
      - GATEWAY_HOST=127.0.0.1
      - RATE_LIMIT_RPM=60
      - ALLOWED_ORIGINS=https://yourdomain.com
    networks:
      - internal

  agent:
    image: openclaw/agent:latest
    read_only: true
    security_opt:
      - no-new-privileges:true
    tmpfs:
      - /tmp:size=100M
    deploy:
      resources:
        limits:
          cpus: "2.0"
          memory: 4G
    networks:
      - internal
    # NO Docker socket mount

networks:
  internal:
    driver: bridge
    internal: true

Let’s break down what changed.

The gateway now binds to 127.0.0.1 only — not reachable from the public internet. Authentication is enabled with a secret token. Rate limiting caps requests at 60 per minute to prevent abuse. CORS is restricted to a single allowed origin.

The agent container runs with a read-only filesystem (read_only: true), meaning the agent can’t modify its own code or configuration. The no-new-privileges flag prevents privilege escalation inside the container. Temporary storage is limited to a 100MB tmpfs mount. CPU and memory are capped to prevent resource exhaustion attacks.

Most importantly, the Docker socket is gone. No volume mount for /var/run/docker.sock. The agent can’t touch the Docker daemon.

Both services communicate over a Docker internal network that has no external connectivity. The only ingress point is the gateway on localhost, which you’d front with a reverse proxy (Caddy, nginx, Traefik) that handles TLS termination and external authentication.

What Firewall Rules Should Every OpenClaw Deployment Have?

Beyond the Docker configuration, your host firewall needs explicit rules. Here’s a minimal iptables baseline:

# Drop all incoming by default
iptables -P INPUT DROP
iptables -P FORWARD DROP

# Allow established connections
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow SSH from your IP only
iptables -A INPUT -p tcp --dport 22 -s YOUR_ADMIN_IP -j ACCEPT

# Allow loopback
iptables -A INPUT -i lo -j ACCEPT

# Block Docker's default bridge network from external access
iptables -A FORWARD -i docker0 -o eth0 -j DROP

The Center for Internet Security (CIS) Docker Benchmark v1.6 recommends these as minimum requirements. In our audits, we’ve found that fewer than 15% of self-deployed OpenClaw instances have any host-level firewall rules configured at all.

For outbound traffic, you need explicit allowlists. Your agent probably connects to the Google Workspace API, Slack’s API, maybe Salesforce or HubSpot. Those specific endpoints should be the only permitted outbound destinations. Everything else gets dropped.

Palo Alto Networks’ 2025 Cloud Security Report found that 82% of self-managed AI installations had misconfigured firewall rules, with overly permissive outbound rules being the number-one cause of data exfiltration.

What Additional Hardening Steps Do Most Guides Miss?

OWASP’s Top 10 for AI Applications and NIST’s AI Risk Management Framework (AI 100-1) both point to areas that go beyond basic network configuration.

Credential isolation. Your agent needs OAuth tokens for Gmail, Slack, Calendar, and other integrations. In most setups, those tokens sit in a .env file or config directory the agent can read directly. If the agent gets compromised, every connected service is compromised too. At beeeowl, we use Composio as credential middleware — the agent sends action requests through Composio but never sees the underlying tokens. Verizon’s 2025 DBIR found that 44% of AI-related breaches involved exposed API credentials.

Audit logging. Every action the agent takes needs to be logged to a location the agent can’t access or modify. That means a separate log volume with append-only permissions, or an external syslog destination. The EU AI Act’s 2025 implementation guidelines require auditable logs for AI systems processing business data. California’s CCPA amendments and Colorado’s AI Act are moving in the same direction.

Container image pinning. Using openclaw/gateway:latest in production means your configuration can change without warning when the image updates. Pin to a specific digest:

image: openclaw/gateway@sha256:a1b2c3d4e5f6...

Snyk’s 2026 State of Open Source Security report found that 29% of container vulnerabilities entered production through unpinned image tags pulling in new, untested versions.

Resource limits. Without CPU and memory limits, a compromised or runaway agent can consume the entire host’s resources — a denial-of-service against yourself. NIST SP 800-190 recommends mandatory resource constraints for all production containers.

How Does beeeowl Handle All of This?

Every beeeowl deployment — whether it’s a $2,000 hosted setup, a $5,000 Mac Mini, or a $6,000 MacBook Air — ships with every hardening measure described in this post. It’s not optional. There’s no “lite” tier without security.

We bind all services to localhost. Authentication is mandatory. Docker sockets are never mounted. Containers run read-only with no-new-privileges. Composio handles credential isolation. Firewall allowlists are configured per client. Audit logs are tamper-proof and stored locally. Images are pinned to tested digests.

We do this because we’ve seen what happens when it’s left to chance. The Censys scan showing 30,000 exposed instances isn’t surprising to us — we’ve audited dozens of self-deployed OpenClaw setups for clients who came to us after their first attempt. The pattern is always the same: the setup guide got them running, but nobody told them the defaults were dangerous — see our guide to OpenClaw.

OpenClaw is excellent software. Jensen Huang compared it to Linux, HTML, and Kubernetes at CES 2025, and he wasn’t wrong — it’s becoming foundational infrastructure. NVIDIA lends engineers directly to OpenClaw’s security advisories. The framework is solid. But solid software still needs proper deployment, the same way a Linux kernel needs a sysadmin who knows what they’re doing.

What Should You Do Right Now If You’re Running OpenClaw?

If you have an OpenClaw instance running anywhere — a cloud VPS, an office server, a personal machine — do these five things today:

1. Check if your gateway is publicly reachable. Run curl http://YOUR_PUBLIC_IP:3000/api/v1/health from an external network. If you get a response, you’re exposed.

2. Enable authentication immediately. Set AUTH_ENABLED=true and generate a strong token secret. This alone blocks CVE-2026-25253.

3. Remove the Docker socket mount. Check your docker-compose.yml for any reference to /var/run/docker.sock. Remove it.

4. Bind services to 127.0.0.1. Change every 0.0.0.0 binding to 127.0.0.1. Use a reverse proxy for external access.

5. Apply the patch. Update to OpenClaw v0.3.28 or later, which includes the fix for CVE-2026-25253. But don’t stop at patching — the default config is still insecure.

If you’d rather not do this yourself, that’s exactly what we built beeeowl to handle. One-day deployment. Every layer hardened from the start. Request your deployment at beeeowl.com.

The 30,000 number from Censys is only going to grow as OpenClaw adoption accelerates. Don’t be a statistic in the next scan.