Over 220,000 OpenClaw Instances Exposed to the Internet, Why Agent Runtimes “Go Naked” at Scale

The headline is about infrastructure, not autonomy

The most misleading framing around OpenClaw is that the security problem is “AI agents getting smarter.” The credible research points to something more boring—and more dangerous: mass deployment plus mass misconfiguration.

SecurityScorecard’s STRIKE team summarizes the core reality clearly: the real risk behind OpenClaw is “access and exposed infrastructure,” with large numbers of internet-facing deployments, many running vulnerable versions. (SecurityScorecard)

Microsoft’s Defender Security Research Team goes further and treats the runtime category itself as a risk boundary shift: OpenClaw blends untrusted instructions with executable code while operating with persistent credentials, which is why Microsoft says it should be treated as “untrusted code execution with persistent credentials” and is “not appropriate” to run on a standard personal or enterprise workstation. (Microsoft)

If you operate security at scale, you already know how this ends: once an admin panel or gateway is internet-reachable, scanners find it; once scanners find it, attackers start testing it; once attackers test it, the weakest link (auth, tokens, plugin ecosystem, patch lag) becomes the compromise point.

What “exposed OpenClaw instances” really means

When reports say “internet-exposed OpenClaw instances,” they may be referring to different measurement methods. This is why the numbers vary widely across credible coverage.

Here are the most common definitions used by researchers and journalists:

• Unique IPs hosting exposed control panels (one IP can host multiple services; one service can move IPs)
• Instance fingerprints (HTTP titles, favicon hashes, UI routes, or protocol behaviors that match OpenClaw variants)
• Actively reachable gateways (a specific port responds to the network)
• Control panels reachable without strong access controls (login pages, missing passwords, weak tokens, or misconfigured proxies)
• Vulnerability exposure (instances that match specific CVEs or show behaviors consistent with exploitability)

SecurityScorecard’s Feb 9 research provides a concrete, defensible baseline: STRIKE identified 42.9K unique IP addresses hosting exposed OpenClaw control panels, with 15.2K appearing vulnerable to RCE at the time, and it notes the dataset is refreshed every 15 minutes. (SecurityScorecard)

Other reporting uses different lenses and later snapshots. The Register described STRIKE’s alarm over “more than 135,000” internet-exposed instances at the time of writing. (The Register)

Hackmag then claimed the live dashboard count grew from 135,000 to more than 220,000, explicitly attributing the jump to rapidly increasing real-time counts. (HackMag)

Infosecurity Magazine highlighted an “over 40,000” finding in early coverage, aligning with the early-phase STRIKE measurements. (Infosecurity Magazine)

Bitsight independently observed 30,000+ exposed instances within a specific analysis window (Jan 27–Feb 8, 2026), which reinforces the scale even if definitions differ. (Bitsight)

Operational takeaway: don’t argue about whether it’s 40K or 220K. Treat it as a fast-moving exposure class that can spike within days—and that your environment may already contain.

Why OpenClaw exposure is more dangerous than a typical web admin panel

It’s tempting to treat OpenClaw like “another self-hosted tool with a UI.” That’s the mistake.

OpenClaw is an agent runtime. Its job is to take actions—often across multiple systems—using credentials you provide. SecurityScorecard frames the escalation risk precisely: if attackers compromise an exposed OpenClaw instance, they inherit whatever access the agent already has (email, cloud services, internal resources, API tokens). (SecurityScorecard)

Microsoft’s warning is fundamentally about how the runtime behaves over time: it can install third-party skills, process unpredictable instructions from outside sources, and retain long-lived tokens/state. That combination weakens the traditional boundary between “trusted installed software” and “untrusted inputs.” (Microsoft)

So when an OpenClaw gateway is reachable, the risk isn’t limited to the server itself. The risk is the entire set of downstream services the agent can touch.

The root cause pattern, defaults plus convenience plus cloud

Default exposure behavior is a multiplier

SecurityScorecard’s Feb 9 research explicitly ties the crisis to convenience-driven deployment and weak access controls, and it documents large-scale exposed control panels across dozens of countries. (SecurityScorecard)

Bitsight adds the “how this happens” operator story: exposing OpenClaw to the public internet is “remarkably easy,” and they observed >30,000 exposed instances in a short window. (Bitsight)

This is the same pattern every security team sees with fast-adoption software:

• a default bind that’s too permissive,
• a “quick start” culture that skips perimeter controls,
• and cloud hosts where “reachable” becomes “public” by accident.

The “agent identity” problem is new for many organizations

SecurityScorecard urges teams to treat agents as additional identities inside the environment with their own access and blast radius. (SecurityScorecard)

That’s not just a metaphor. When an agent has OAuth grants, API keys, and messaging integrations, it becomes a high-privilege actor that doesn’t look like a human login—meaning many orgs won’t catch misuse until after damage.

The most repeated, highest-intent search phrases in top coverage

You asked for the highest-click terms around this topic. Public sources don’t provide universal CTR numbers, but you can extract something defensible: the repeated headline language and repeated technical hooks across the most linked, high-authority coverage. Those repeats strongly correlate with what people search when they’re trying to fix something under pressure.

Across Microsoft, SecurityScorecard STRIKE, Bitsight, Hunt.io, The Hacker News, Oasis, Endor Labs, and major tech/security news, the most repeated high-intent phrases are:

• “OpenClaw instances exposed to the internet” and “internet-exposed OpenClaw” (The Register)
• “exposed control panels” and “publicly accessible control panel” (SecurityScorecard)
• “CVE-2026-25253” and “/api/export-auth token theft” (hunt.io)
• “ClawJacked” and “malicious website hijacks local agent via WebSocket” (oasis.security)
• “ClawHub malicious skills” and “hundreds of malicious skills” (The Verge)
• “untrusted code execution with persistent credentials” (Microsoft’s phrasing is quoted widely) (Microsoft)
• “SSRF / webhook auth / path traversal” in OpenClaw tooling and ecosystem disclosures (endorlabs.com)

If you want search traffic that maps to real remediation work, these are the phrases that consistently show up where serious engineers are reading.

The realistic attack paths defenders should assume

This section avoids exploit step-by-step details and focuses on the abuse chains that matter for risk reduction.

Path 1, exposed control panel or gateway becomes “permission inheritance”

SecurityScorecard’s STRIKE team explains why RCE in agentic environments is uniquely dangerous: the attacker doesn’t just get code execution—they get the agent’s integrations and authority. (SecurityScorecard)

Even when it isn’t RCE, a reachable control plane often exposes:

• configuration,
• installed skills,
• auth tokens,
• and the “shape” of the environment (which helps targeted exploitation).

Path 2, credential theft via CVE-2026-25253, the “token leaves your machine” class

Hunt.io’s research is direct: they identified 17,500+ internet-exposed OpenClaw/variants vulnerable to CVE-2026-25253, and the vulnerability allows unauthenticated access to stored API tokens via /api/export-auth. (hunt.io)

NVD’s description makes the class of bug clear: affected versions obtain a gatewayUrl from a query string and auto-connect via WebSocket, sending a token value—turning a crafted link or override into token exfiltration behavior. (NVD)

In practice, once a token is gone, the rest of the agent’s connected systems become reachable in the ways that token permits.

Path 3, local workstation takeover via “ClawJacked” WebSocket chain

Oasis Security describes a vulnerability chain where a website can silently take control of a developer’s OpenClaw agent via localhost WebSocket behavior, recommending updating to 2026.2.25 or later. (oasis.security)

SecurityWeek’s report on the same class of issue summarizes the abuse: malicious websites could open a WebSocket connection to localhost on the OpenClaw gateway port, brute-force passwords, and take control of the agent. (SecurityWeek)

Some coverage reports the patch as 2026.2.26 (likely reflecting a specific release line after the initial fix), so the safest practical guidance is: update to the latest fixed release and verify the fix is actually present. (Security Affairs)

Path 4, supply chain compromise via skills, the marketplace becomes an attack surface

The Verge reports that hundreds of skills in ClawHub contained malware and emphasizes that skills can execute with broad access to local files and networks, escalating the impact of a malicious extension. (The Verge)

Tom’s Hardware details a narrower slice—at least 14 malicious skills uploaded in late January 2026—illustrating how quickly attackers tested the ecosystem. (Tom’s Hardware)

Trend Micro documents malicious OpenClaw skills being used to distribute Atomic macOS Stealer, showing that the ecosystem is already being used as a malware delivery channel. (www.trendmicro.com)

VirusTotal’s own blog describes detecting hundreds of actively malicious skills and frames the marketplace as a new supply-chain vector. (blog.virustotal.com)

This is not theoretical. It is already an active distribution layer.

The CVE map that matters most, prioritized for real-world defense

The goal here is not to list every advisory. The goal is to surface the CVEs that map to the most likely compromise paths: token theft, command injection, file disclosure, and tool-bridge vulnerabilities.

High-impact OpenClaw CVEs and what they mean

CVE	What it enables, plain English	Typical preconditions	Fixed version signal
CVE-2026-25253	Token theft via gateway URL override + auto WebSocket connection behavior, leading to account compromise patterns	User interaction or exposed UI patterns depending on deployment; token stored client-side and sent out	NVD references affected versions “before 2026.1.29” in its entry (NVD)
CVE-2026-25593	Unauthenticated local client can use Gateway WebSocket config to set unsafe path values leading to command injection as gateway user	Local adjacency; still serious on shared hosts/dev boxes	Fixed in 2026.1.20 per NVD (NVD)
CVE-2026-24763	Command injection risk in Docker sandbox execution due to unsafe PATH handling	Authenticated user controlling env variables; risky in privileged/misconfigured container setups	Fixed in 2026.1.29 per NVD (NVD)
CVE-2026-25157	OS command injection via project root path in SSH remote handling	Scenarios using SSH node commands; remote host impact	Affected before 2026.1.29 per NVD (NVD)
CVE-2026-25475	Local file disclosure via MEDIA: path staging, allowing reading arbitrary files if the agent outputs that path	Requires privileges that allow agent to read files; high-value in real environments	Patched in 2026.1.30 per NVD (NVD)

Vulnerabilities discovered via modern code-flow analysis, not guesswork

Endor Labs reports discovering six vulnerabilities in OpenClaw using data flow analysis and validating working exploits, with CVEs including CVE-2026-26319, CVE-2026-26322, and CVE-2026-26329 among the set described publicly. (endorlabs.com)

For defenders, the value of this work is that it highlights how tool-bridging features (webhooks, upload paths, SSRF-adjacent behaviors) become escalation points in agent runtimes.

24-hour triage checklist, reduce risk fast without breaking everything

This section is designed for security teams who need immediate action, and it assumes you are scanning only networks and systems you own or are authorized to test.

1) Find every host that looks like OpenClaw

Start with port and service discovery, then validate with host-level checks.

# Authorized scanning only.
# Look for the gateway/control-plane port commonly referenced in incident coverage.
nmap -sS -sV -p 18789 --open <YOUR_CIDR_RANGES>

If you have EDR inventory, search installed packages or process names associated with your OpenClaw deployment patterns.

2) Confirm whether the service is bound to public interfaces

On Linux:

sudo ss -lntp | grep -E ':18789\\b' || true
sudo lsof -nP -iTCP:18789 -sTCP:LISTEN || true

If you see 0.0.0.0:18789 or :::18789, treat it as internet-reachable unless your network controls block it.

3) Remove public reachability first, then perfect authentication

If an instance is reachable from the internet, the safest short-term fix is to block it at the perimeter. You can add stronger auth later, but you cannot “auth your way out” of unpatched RCE/token-theft classes fast enough.

Example with UFW:

# Block public access to the OpenClaw gateway/control port
sudo ufw deny 18789/tcp

# Allow only from VPN/private admin ranges (example)
sudo ufw allow from 10.8.0.0/24 to any port 18789 proto tcp

4) Patch with urgency, then rotate secrets as if exposure occurred

Microsoft recommends isolation, limited credentials, and rebuild plans for a reason: if an agent was reachable, you have to assume downstream compromise paths exist. (Microsoft)

Patch priorities based on public disclosures:

• Update beyond the fixed releases for ClawJacked-class issues (Oasis recommends 2026.2.25+) (oasis.security)
• Patch token-theft behaviors related to CVE-2026-25253 (NVD)
• Patch command injection and file disclosure CVEs outlined in NVD entries (NVD)

Then rotate:

• API keys for LLM providers
• OAuth refresh tokens and app approvals
• any secrets the agent could read locally (SSH keys, cloud credentials, service account tokens)

If you cannot quickly enumerate what the agent had access to, that is itself a signal your deployment model needs rethinking.

Secure deployment blueprint, what “good” looks like for an agent runtime

Rule 1, treat the runtime as disposable and isolate it

Microsoft’s guidance is clear: evaluate only in a fully isolated environment (dedicated VM or separate physical system), using dedicated non-privileged credentials and non-sensitive data. (Microsoft)

If you do only one thing, do this.

Rule 2, bind locally and control ingress explicitly

If you use Docker, avoid publishing the port broadly:

# Prefer localhost binding to prevent accidental public exposure
docker run --name openclaw \\
  -p 127.0.0.1:18789:18789 \\
  --restart unless-stopped \\
  openclaw/openclaw:latest

Then provide access via VPN or private tunnel rather than public IPs.

Rule 3, enforce least-privilege integrations and separate identities

SecurityScorecard’s STRIKE team urges teams to treat agents as identities with their own blast radius. (SecurityScorecard)

Translate that into control design:

• separate service accounts for the agent
• minimal OAuth scopes
• no access to production cloud consoles unless required
• no read access to secrets folders by default
• use short-lived credentials where possible

Rule 4, skills are a supply chain, allowlist and review

Even OpenClaw’s own blog acknowledges that skills run in the agent’s context with access to tools and data—and that malicious skills can exfiltrate information or execute unauthorized commands. (OpenClaw)

Given the ecosystem has already been abused at scale, you should:

• allowlist approved skill sources
• pin versions and verify hashes
• require code review for any skill that can execute commands or access sensitive stores
• disable skills you don’t need

Rule 5, use scanning and telemetry, but don’t confuse scanning with safety

OpenClaw announced a VirusTotal partnership to scan skills and display scan results in version history. (OpenClaw)

That helps, but it does not solve instruction-level attacks, social engineering, or logic-layer abuse.

VirusTotal also describes the marketplace as a malware delivery channel, which should set your expectation: this ecosystem will remain a target. (blog.virustotal.com)

Monitoring and detection, catch abuse before it becomes “quiet persistence”

A core point in Microsoft’s write-up is that persistence may look like configuration drift and legitimate OAuth approvals rather than obvious malware. (Microsoft)

So your monitoring needs to include identity and behavior signals, not just binaries.

1) Detect exposure policy violations

A simple host check you can run via your config management system:

# Exit non-zero if the gateway is listening on all interfaces
if ss -lntp | grep -qE '0\\.0\\.0\\.0:18789|:::18789'; then
  echo "Policy violation: OpenClaw port 18789 bound to all interfaces"
  exit 2
fi
exit 0

2) Watch for suspicious outbound patterns

For agent hosts, alert on:

• new domains contacted shortly after skill installs
• requests to cloud metadata IPs (for example, 169.254.169.254) from unexpected workloads
• sudden spikes in LLM provider API usage tied to agent tokens
• outbound connections to paste sites or webhook collectors

Endor Labs’ disclosure work highlights why SSRF-adjacent tool surfaces matter in agent runtimes, because “tool inputs” can become network actions. (endorlabs.com)

3) Identity telemetry, watch OAuth grants and token refresh behavior

If your agent uses OAuth, log:

• new app consents
• scope changes
• refresh token creation
• unusual access times or locations

Treat the agent as a non-human identity that needs the same governance you apply to service accounts.

Incident response, if you were exposed, assume downstream impact

If an OpenClaw control plane or gateway was internet-reachable, do not stop at “we closed the port.”

Your IR plan should include:

1. Containment

• remove public exposure at network edge
• isolate the host (quarantine segment)
• snapshot disk and memory if you need forensic evidence

1. Credential rotation

• rotate all LLM provider API keys
• revoke/rotate SaaS tokens and OAuth grants
• rotate SSH keys and cloud credentials accessible to the agent Hunt.io’s research shows how directly token exposure maps to real compromise potential. (hunt.io)

1. Behavior review

• review agent logs and action histories for unexpected tool execution
• inspect installed skills/extensions and recent changes
• check for new scheduled jobs, cron entries, or persistence mechanisms

1. Rebuild Microsoft explicitly recommends a rebuild plan as part of the operating model for evaluating such runtimes. (Microsoft)

If your team is already running authorized security validation, the OpenClaw exposure story is fundamentally a verification problem: you need to know where the runtime is deployed, whether it is reachable, whether known fixes are actually present, and whether integrations are scoped safely.

That’s where an AI-assisted penetration testing platform like Penligent can be useful in a concrete way: automating evidence-based verification of exposure conditions (reachable ports, misconfigured proxies, unauthenticated control paths) and producing repeatable remediation proof you can share with engineering and leadership.

Penligent has also published focused research that treats the OpenClaw skill ecosystem as a supply-chain boundary—useful context when you’re building governance for skills and extension review pipelines. (penligent.ai)

Summary, what security teams should say out loud

• The OpenClaw incident wave is not mainly about “AI going rogue.” It’s about agent runtimes being deployed like toys while holding real credentials. (SecurityScorecard)
• Reported exposure counts vary because measurement methods vary, but multiple independent sources still show mass-scale exposure in short windows. (SecurityScorecard)
• The most important defensive moves are the classic ones—restrict exposure, patch quickly, rotate secrets, isolate runtimes—but you must apply them as if you’re securing a privileged identity, not a normal app. (SecurityScorecard)
• The skill marketplace is already an active malware delivery channel; treat it as a supply-chain threat model, not an app store convenience. (The Verge)

References

Microsoft Security Blog: Running OpenClaw safely: identity, isolation, and runtime risk https://www.microsoft.com/en-us/security/blog/2026/02/19/running-openclaw-safely-identity-isolation-runtime-risk/

SecurityScorecard STRIKE: Beyond the Hype — exposed infrastructure, counts, and RCE risk https://securityscorecard.com/blog/beyond-the-hype-moltbots-real-risk-is-exposed-infrastructure-not-ai-superintelligence/

SecurityScorecard STRIKE: How exposed OpenClaw deployments turn agentic AI into an attack surface https://securityscorecard.com/blog/how-exposed-openclaw-deployments-turn-agentic-ai-into-an-attack-surface/

Bitsight: OpenClaw AI security risks, 30,000+ exposed instances observed in a defined window https://www.bitsight.com/blog/openclaw-ai-security-risks-exposed-instances

NVD: CVE-2026-25253 https://nvd.nist.gov/vuln/detail/CVE-2026-25253

NVD: CVE-2026-25593 https://nvd.nist.gov/vuln/detail/CVE-2026-25593

NVD: CVE-2026-24763 https://nvd.nist.gov/vuln/detail/CVE-2026-24763

NVD: CVE-2026-25157 https://nvd.nist.gov/vuln/detail/CVE-2026-25157

NVD: CVE-2026-25475 https://nvd.nist.gov/vuln/detail/CVE-2026-25475

Oasis Security: OpenClaw vulnerability chain (ClawJacked) and patch guidance https://www.oasis.security/blog/openclaw-vulnerability

Endor Labs: Six OpenClaw vulnerabilities discovered via data flow analysis https://www.endorlabs.com/learn/how-ai-sast-traced-data-flows-to-uncover-six-openclaw-vulnerabilities

OpenClaw official blog: VirusTotal partnership for ClawHub skill scanning https://openclaw.ai/blog/virustotal-partnership

VirusTotal blog: From Automation to Infection — OpenClaw skills as a malware vector https://blog.virustotal.com/2026/02/from-automation-to-infection-how.html

Penligent: OpenClaw + VirusTotal — The skill marketplace as a supply-chain boundary https://www.penligent.ai/hackinglabs/openclaw-virustotal-the-skill-marketplace-just-became-a-supply-chain-boundary/