Original Research

The Anatomy of an Exposed OpenClaw Instance — A Real-World Teardown

What an attacker sees when they find your AI agent on the open internet

Taylor Haun·March 20, 2026·7 min read

The Anatomy of an Exposed OpenClaw Instance — A Real-World Teardown

When I published my exposure report on 8,600+ open OpenClaw instances, the most common response was: "But what can someone actually do with an exposed instance?"

Fair question. Let me walk you through exactly what an attacker sees — step by step — when they find an unprotected OpenClaw server on the internet. This is based on real Shodan data from our scan, with identifying details removed.

Step 0: Finding the Target

An attacker doesn't need to be sophisticated. They need one Shodan query:

product:"OpenClaw" port:18789

Shodan returns 8,600+ results. Each one includes the IP address, port, geographic location, hosting provider, and a banner — the server's response to a basic connection. That banner is the first fingerprint.

Step 1: The Banner (What Shodan Sees)

Here's what a typical OpenClaw banner looks like in Shodan data:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 692
Server: OpenClaw/1.x

What this tells an attacker immediately:

  • HTTP/1.1 200 OK — The server responded successfully. No authentication challenge (no 401 Unauthorized, no WWW-Authenticate header). It just let us in.
  • Content-Length: 692 — This is the default landing page size. We saw this exact value on 75.4% of instances. It means the operator hasn't modified anything — it's a stock install, fresh out of the box.
  • No SSL/TLS — The connection is plain HTTP, not HTTPS. Everything transmitted is in cleartext.
  • Server header — Confirms the software and version. Older instances expose the Moltbot header, which signals outdated software with known vulnerabilities.

In our scan of 1,200 instances, 100% returned 200 OK with no authentication header. Not a single one asked for credentials.

Step 2: The Landing Page

Connecting to http://[IP]:18789 in a browser loads OpenClaw's default web interface. On a stock installation, this shows:

  • The OpenClaw UI shell
  • A list of available AI models
  • A chat interface ready to accept prompts
  • Navigation to settings, agents, and tools

No login screen. No password prompt. Just the full application, ready to use.

An attacker is now sitting in the same seat as the legitimate operator. They can see everything the operator sees.

Step 3: The API Surface

Behind the web UI sits a REST API. This is where the real attack surface lives. Key endpoints that are typically accessible:

Model discovery: The API exposes what AI models are configured. This tells the attacker what capabilities the instance has and, more importantly, which upstream API keys are in use (Anthropic, OpenAI, local models, etc.).

Chat and conversation endpoints: The attacker can start new conversations with any configured model — using the operator's API keys and compute resources. They can also access existing conversations if the instance stores chat history.

Agent and tool configuration: OpenClaw agents can be connected to external tools — file systems, databases, email, web browsers, code execution environments. The configuration endpoints reveal which tools are enabled and how they're connected.

Settings and configuration: System-level settings, including potentially API keys stored in configuration files that the instance reads at startup.

Step 4: What's Exposed (Real Examples from Our Data)

From our scan data, here's what we found across the 1,200 instances:

Custom Assistant Names

Many operators configure personalized AI assistants with custom names and personas. We found names like:

  • "Winston" — Suggests a personal assistant or butler-style agent
  • "Ryan" — A named business assistant

These names reveal that real people are using these instances for real work. These aren't forgotten test deployments — they're active agents that someone named, configured, and uses regularly.

Software Versions

  • 75.4% running current OpenClaw with default content (stock install, no hardening)
  • 24.6% running older Moltbot-based versions with known security issues

The older versions are particularly concerning. They haven't been updated, which suggests abandoned or unmaintained deployments — servers that were set up once and forgotten. These are the most likely to contain stale API keys that are still valid.

Hosting Fingerprints

The Shodan data includes details about the hosting environment:

  • SSH server versions (many running older OpenSSH builds)
  • Operating system fingerprints
  • Other services running on the same IP (some instances run alongside web servers, databases, or other applications on the same machine)

An attacker can use this to identify additional attack vectors on the same host. A vulnerable SSH server or an outdated web application running alongside OpenClaw could provide an alternate path to compromise the machine entirely.

Step 5: The Attack Scenarios

With full unauthenticated access, an attacker can:

Credential Harvesting

Extract API keys for upstream services (Anthropic, OpenAI, Google, etc.). These keys often have broad permissions and are expensive to abuse. A stolen Anthropic API key could rack up thousands of dollars in API calls before the operator notices.

Time to exploit: Seconds. Just read the configuration.

Chat History Mining

Browse existing conversations for sensitive information. Business users discussing strategy, financial data, customer information, or internal processes through their AI agent have left a trail. Anyone who finds the instance can read it.

Time to exploit: Minutes. Browse the conversation history through the UI.

Compute Theft (Cryptojacking the AI Way)

Use the operator's infrastructure and API credits to run your own workloads. Why pay for Claude API access when there are 8,600+ instances with valid API keys sitting open?

Time to exploit: Immediate. Start a conversation and use the configured model.

Prompt Injection for Lateral Movement

If the OpenClaw instance has tools connected to internal systems — a database, a file server, an email account, a code repository — an attacker can use prompt injection to manipulate the agent into accessing those systems.

Example: If the agent has email tool access, an attacker could craft a prompt that causes the agent to forward emails, send messages, or extract contact lists. The agent does the work; the attacker just provides the instructions.

Time to exploit: Minutes to hours, depending on the connected tools and the sophistication of the prompt injection.

Persistent Backdoor

Modify the agent's system prompt to include hidden instructions. Every future conversation the legitimate operator has with their agent is now compromised — the agent subtly follows the attacker's injected instructions alongside the user's requests.

This is particularly dangerous because it's invisible. The operator doesn't see the modified system prompt in normal usage. The agent behaves normally on the surface while quietly exfiltrating data or manipulating outputs.

Time to exploit: Minutes. Modify the system prompt through the UI.

The Scoring Model

Not all exposed instances are equal. We built a three-axis scoring system to prioritize:

Vulnerability Score (40% weight)

How exposed and exploitable is the instance?

  • No authentication: +25 points (100% of instances)
  • No SSL/TLS: +20 points (100% of instances)
  • Default content length (stock install): +10 points (75.4%)
  • Direct port 18789 exposure: +5 points (100%)
  • Old Moltbot version: +35 points (24.6%)

Business Signal Score (35% weight)

Is this a real organization worth reaching out to?

  • Real domain name found: +35 points
  • Hosted on a Western cloud provider: +25 points
  • Organization name in WHOIS/IP registry: +15 points
  • Foreign cloud hosting: -40 points (likely noise, not a real US business lead)

Reachability Score (25% weight)

Can we find and contact the operator?

  • Domain name resolves: +40 points
  • Organization + domain match: +20 points
  • WHOIS email available: +10 points

The highest-scoring instances combine all three: a serious vulnerability profile, a real business behind the IP, and a clear path to contact. These are the ones most at risk — and most likely to benefit from professional hardening.

The Timeline of Compromise

Here's how fast this plays out:

ActionTime
Find target on Shodan30 seconds
Confirm no authentication5 seconds
Browse chat history2 minutes
Extract API keys1 minute
Map connected tools5 minutes
Inject persistent backdoor10 minutes
Total time to full compromise< 20 minutes

Compare that to the 15 minutes it takes to secure the instance. The attacker's timeline is actually shorter than the fix.

What To Do Right Now

  1. Check if you're exposed. Search Shodan for your server IP or run curl http://YOUR_IP:18789.

  2. If you are: secure it immediately. Bind to localhost, set up a reverse proxy with auth, enable SSL, firewall the port.

  3. Rotate your API keys. If your instance was exposed, assume your upstream API keys (Anthropic, OpenAI, etc.) are compromised. Regenerate them now.

  4. Audit your chat history. Review what conversations happened through the exposed agent. Assess what sensitive data may have been accessible.

  5. Check what tools were connected. If your agent had access to email, databases, or file systems, review those systems for unauthorized access.

The 8,600+ exposed instances aren't going away on their own. Every day they're online is another day of exposure. The anatomy of compromise isn't complex. It's simple, fast, and fully automated.

Lock the door.


Need help assessing your exposure? I'll check your OpenClaw instance for free and tell you exactly what's visible from the outside. haunlab.com/free-audit

— Taylor Haun, Haun Labs

TH
Taylor Haun

Software engineer. Former Spotify. Building AI agent security tools at Haun Lab.

Is your OpenClaw instance exposed?

Get a free exposure report. We'll scan public databases for your instance and tell you exactly what's visible from the outside.

Get your free audit