OpenClaw's exposed control panels: 15,200 hosts flagged for remote code execution

SecurityScorecard's STRIKE threat-intelligence team spent a day scanning the public internet for OpenClaw control panels in early February 2026 and reported on 9 February that it had found 42,900 unique IP addresses answering across 82 countries, of which 15,200 appeared vulnerable to remote code execution. Cyber Security News carried the findings on 10 February 2026, the date the record carries. The panels are the gateway console of a self-hosted AI agent that runs with its owner's file access, so the same research says a compromised instance hands over SSH keys, cloud credentials and live browser sessions. No named victim and no confirmed mass takeover appears in the sources read for this piece. The full record, with its severity and confidence grades, sits in the Orca AI Incident Archive, beside the other OpenClaw entries from the same month.

What makes the number worth reading carefully is that it is not the number in the headline. The 15,200 figure is the subset STRIKE judged exploitable, not the population it found exposed. The same team put the total at 42,900 unique IP addresses, and its own live dashboard, declawed.io, was still counting.

What the scan counted, and why its numbers do not agree

STRIKE's method was fingerprinting rather than login attempts. The team matched the favicon files OpenClaw serves across its three branding eras, cross-referenced TLS certificate common names, reverse DNS and certificate-transparency logs, and pulled in SecurityScorecard's own breach and threat-actor data. Its published progression is a useful measure of how fast the picture moved: a title-based search found 24,034 instances, favicon fingerprinting confirmed 40,214, and 23,505 of those showed an active control-panel interface (SecurityScorecard, 9 February 2026).

The headline counts are what the report's executive summary gives: 42.9K unique IP addresses across 82 countries, 15.2K instances flagged vulnerable to RCE, which the report expresses as 35.4% of observed deployments, 24K+ instances associated with known CVEs, and 53.3K instances claimed to correlate with prior breach activity. That last figure is larger than the 42.9K total it is supposed to sit inside, and SecurityScorecard does not explain the discrepancy in the post. The report also says the counts refresh every 15 minutes, which means any single snapshot is a moving target.

A second, independent reading of the same research landed the same day and does not match. Infosecurity Magazine reported 40,214 exposed instances associated with 28,663 unique IP addresses, 12,812 exploitable via RCE, which it put at 63% of observed deployments, 549 instances correlated with prior breach activity, and 1,493 with known vulnerabilities (Phil Muncaster, 9 February 2026). The two accounts disagree by a factor of nearly a hundred on breach correlation, and their estimates of how many hosts are actually exploitable differ almost twofold. They cannot both be describing the same population with the same denominator, and neither source states which denominator it used. The archive's own figure, 15,200, comes from the first of these accounts.

An agent's control panel is not a web page

The reason a misbound port matters here is what sits behind it. An OpenClaw gateway holds the credentials the agent uses to act: the credentials directory at ~/.openclaw/credentials, SSH keys in ~/.ssh, browser profiles with live sessions, and the messaging accounts the agent speaks through. SecurityScorecard's list continues to cron jobs and heartbeat hooks an attacker could use for persistence, and to what it calls the agent's memory context, everything the agent knows about its owner.

That inheritance is the actual finding, and the report states it without decoration: "Agentic AI does not create new classes of vulnerability. It inherits old ones and amplifies their impact." The agent is not the vulnerability. It is the privilege that an ordinary exposed admin panel now carries.

The default binding claim, and where it is narrower than it sounds

SecurityScorecard's causal claim is blunt: "Out of the box, OpenClaw binds to 0.0.0.0:18789, meaning it listens on all network interfaces, including the public internet. For a tool this powerful, the default should be 127.0.0.1 (localhost only). It isn't."

That is true of one deployment path and not of another, and the difference matters to anyone deciding whether they are affected. In the project's own docker-compose.yml at tag v2026.1.29, the gateway container is started with the flag --bind ${OPENCLAW_GATEWAY_BIND:-lan}, which defaults to the LAN address, and the same file publishes port 18789 on the host with no address prefix, which binds it to every host interface. The native command-line gateway is different: in src/cli/gateway-cli/run.ts at the same tag, the bind value falls back to "loopback" when neither a flag nor a config setting is present, and the process refuses to start on a non-loopback address without a shared secret. A community code review published in the explain-openclaw repository makes the same distinction, arguing that the "out of the box" phrasing conflates the compose default with the native CLI default.

This does not shrink the exposure the scan found. A container deployed from the project's own compose file onto a cloud host is precisely the shape of deployment a favicon scan would light up, and the older pre-rename builds the report counts as the majority may well have been more permissive than either current default. It does mean the practical question for an operator is which of those two paths they used, not whether OpenClaw is inherently public-facing.

Three CVEs, one patch release, and a score that depends on who is counting

The three vulnerabilities STRIKE cites were all fixed in version 2026.1.29, whose GitHub release is timestamped 05:26 UTC on 30 January 2026. CVE-2026-25253 is the one-click RCE through a gatewayUrl parameter, scored 8.8 in NVD's record, a score MITRE supplied. CVE-2026-24763 is the Docker sandbox escape via PATH manipulation, also 8.8, scored by GitHub's advisory. CVE-2026-25157 is the SSH command injection in the macOS app.

The third score is where the circulating numbers part company. SecurityScorecard's post and the Cyber Security News report both give it as 7.8. Read on 5 November 2026, NVD's record carries 7.7 from the GitHub advisory that serves as the CNA for the issue, and 7.5 from NIST as the primary scorer. The scores are close, but they are not the same number, and the 7.8 that travels with the trade coverage is not the one in either current NVD entry.

One property of CVE-2026-25253 deserves its own sentence, because it changes the mitigation advice: SecurityScorecard notes that the token-theft chain works "even if the instance is bound to localhost." Binding to 127.0.0.1 closes the direct-access route the scan measured. It does not close that one.

The fix release was not only a set of CVE patches. Its notes record a breaking change, that the gateway auth mode "none" is removed and the gateway now requires a token or password, along with a doctor warning when the gateway is exposed without auth. A build old enough to still call itself Clawdbot or Moltbot predates all of that.

78% is a branding label, not a version string

The record's claim that the CVEs are widely unpatched rests on a proxy. STRIKE split the 23,505 active panels by the title they served: Clawdbot Control 9,280 (39.5%), Moltbot Control 9,048 (38.5%), and OpenClaw Control 5,177 (22.0%). From that the report concludes that 78% of exposed instances "have run older versions with names that predate critical security patches," and adds the word "suggests" in the next sentence.

It is a reasonable inference and it is still an inference. The panel title is a string the build writes about itself, and the report does not publish a version histogram. A deployment can serve the current title and still be months behind, which the report itself concedes when it says the 22% on OpenClaw branding "may still be outdated builds." The direction of the finding, that most exposed deployments are old, is corroborated by the shape of the ecosystem rather than by a patch-level census.

The threat-actor line, and the caveat attached to it

This is the part of the record most likely to be quoted out of context, so it is worth setting out exactly what the primary source says. STRIKE writes that some instance IPs correlate with infrastructure previously attributed to named groups, listing Kimsuky, APT28, Salt Typhoon, Sandworm and APT41. It then defines what that means: the IP address or its hosting infrastructure was previously observed in connection with that group's operations, so an instance "linked to Kimsuky" is one whose hosting has been flagged in threat-intelligence feeds. And it adds the sentence that the summaries drop: "This is an intelligence signal, not proof of direct operation."

The percentage is a separate measurement with a separate denominator. SecurityScorecard says approximately 33.8% of enriched instances show breach correlation, which it defines as the hosting organisation having appeared in prior data breach records. That is a statement about the security history of the host, not about an APT operating the panel. The Cyber Security News report renders it as "approximately 33.8% of the exposed infrastructure correlates with known threat actor activity," and the archive's summary carries a version of that framing. Read against the primary source, the 33.8% is breach correlation among an enriched subset, and the threat-actor correlation is an unnamed, smaller quantity that the vendor explicitly declines to treat as proof.

What was actually harmed

The archive grades this record as an incident with real harm, high severity and confidence A. What the cited sources document is exposure rather than a body count: live agents reachable from the open internet, credentials sitting behind an unauthenticated panel, and a large share of hosts whose operators have already appeared in breach data. Neither SecurityScorecard nor Infosecurity Magazine names a victim, a ransom, a data set taken, or a single confirmed takeover traced to an exposed panel. The harm recorded is the standing opportunity, measured at scale, plus the vendor's own correlation that a third of the enriched hosts were already compromised elsewhere.

That distinction should survive the reading. An exposure finding of this size is not evidence that the exposures were used, and the sources read here do not claim they were.

What the researchers told operators to do

SecurityScorecard's remediation list is specific and mostly about undoing the default: patch to v2026.2.1 or later, which is later than the release that fixed the three CVEs; set gateway.bind to "127.0.0.1"; reach the panel through Tailscale, WireGuard, Cloudflare Tunnel or ngrok rather than an open port; rotate every token and API key stored in the agent, treating them as already compromised; run openclaw security audit deep; never run the framework as root; and, for security teams, block port 18789 at the perimeter and watch for command-and-control-shaped outbound traffic from internal workstations.

Two of those deserve emphasis because they are easy to skip. The credential rotation is not conditional on evidence of compromise, because the panel that would have exposed the keys is the same panel that authenticates them. And the patch floor is not 2026.1.29 even though that is where the three CVEs were fixed, because STRIKE's own recommendation is 2026.2.1 or later.

The researchers also published their counter. The declawed dashboard at declawed.io presents the exposure counts, per-instance CVE status and breach correlation, refreshed every 15 minutes, which is the only way to read figures that were moving this fast as a trend rather than a headline.

Established, reported, unresolved

The parts that hold up across sources: OpenClaw's gateway holds the credentials its agent acts with; the project's docker-compose file at v2026.1.29 publishes port 18789 on all host interfaces and passes a LAN bind by default; three named CVEs were fixed in v2026.1.29, released on 30 January 2026; and a large internet-wide scan found tens of thousands of exposed panels, a figure both SecurityScorecard and Infosecurity Magazine put at or above 40,000 in some unit.

The parts that are vendor-reported and not independently reproduced: the 42.9K and 15.2K counts, the 82-country spread, the 53.3K breach-correlation figure, the 33.8% enriched breach rate, and the 78% pre-patch inference. Infosecurity Magazine's different set of numbers is a second reading of the same research, not an independent measurement, and no third party has re-run the scan.

The parts that remain open: which denominator each published count used, why the breach-correlation total exceeds the IP total in the vendor's own summary, whether the APT-correlated addresses reflect operators using OpenClaw or infrastructure that happens to host it, and whether any exposed panel was actually taken over. The sources read for this piece answer none of those, and the record does not claim they do.