From Personal Assistant to Public Target

OpenClaw started life as an open-source personal AI assistant - the kind of tool you run on your own devices to manage tasks, automate workflows, and interface with various services through a plugin-like system called "skills." By early 2026, the project (also known by its older names Clawdbot and Moltbot) had attracted a substantial user base drawn to its promise of local-first, privacy-respecting AI. That promise began to unravel on February 9 when SecurityScorecard's STRIKE threat intelligence team published the results of an internet-wide scan revealing just how many of those supposedly private instances were anything but.

The headline number was staggering: over 135,000 OpenClaw instances directly accessible from the public internet. Earlier the same day, the count had been around 40,000, and it kept climbing as researchers expanded their scanning methodology. These were not honeypots or test deployments. They were real installations exposed because OpenClaw's default network configuration binds its gateway server to all network interfaces - meaning that unless a user explicitly locked it down, their AI assistant was essentially hanging a welcome sign on the internet.

Three CVEs, One Very Bad Week

The exposure problem would have been concerning on its own, but it arrived alongside three critical vulnerabilities that turned misconfigured instances into fully exploitable targets.

CVE-2026-25253 (CVSS 8.8) was the most attention-grabbing. OpenClaw's gateway accepts a gatewayUrl parameter from a query string and automatically establishes a WebSocket connection, sending along the user's authentication token without any user confirmation. Because WebSockets do not carry the same Cross-Origin Resource Sharing protections as standard HTTP requests, and because the OpenClaw gateway did not validate the origin of incoming WebSocket connections, an attacker could craft a malicious web page that silently captured the user's token. Once stolen, that token granted a full session with the gateway - the attacker could send messages to the AI agents and instruct them to execute arbitrary commands. The attack chain worked in two stages: a first page phished the token via the rogue WebSocket connection, and a second page implemented the gateway's signature validation algorithm, established its own WebSocket session, and issued commands as the legitimate user. This was effectively one-click remote code execution.

CVE-2026-24763 targeted a related weakness: an OS command injection flaw (CWE-78) in the gateway that allowed authenticated users - or anyone with a stolen token - to execute arbitrary system commands. Combined with CVE-2026-25253's token theft, this turned every exposed instance into a potential backdoor.

CVE-2026-25157 rounded out the trio, adding another vector for remote code execution against unpatched instances. All three vulnerabilities affected OpenClaw versions before 2026.1.29.

Approximately 50,000 of the 135,000+ exposed instances were confirmed vulnerable to at least one of these RCE flaws. That is not 50,000 theoretical attack surfaces. That is 50,000 machines where an attacker could potentially read files, steal credentials, pivot through messaging platforms, and access whatever personal data the AI agent had been granted permission to touch.

What the Scanning Revealed

Hunt.io published a detailed analysis of the exposed instances, using SQL-based queries to fingerprint deployments at scale. Among 17,470 instances with identifiable HTML titles, the Clawdbot Control variant dominated at 68.9% of deployments, followed by Moltbot Control at 22.3% and the original OpenClaw Control at 8.8%. The detection methodology combined HTML title matching, HTTP header fingerprinting, body hashing, asset identification, certificate analysis, and content-length filtering to achieve thorough coverage.

SecurityScorecard's STRIKE team also reported that over 53,000 of the exposed instances showed links to previous data breaches, suggesting that the machines hosting these AI agents had already been compromised at some point. Running an internet-facing AI agent on a device with a breach history is the security equivalent of installing a new front door while the back wall is already missing.

The Malicious Skills Problem

The exposure and vulnerability story was bad enough. Then Bitdefender Labs dropped a companion finding that made it worse.

Their analysis of skills published on ClawHub - OpenClaw's public registry where users discover and install plugins for their AI agents - found that approximately 17% of the skills analyzed during the first week of February 2026 exhibited malicious behavior. Nearly 900 malicious skills were identified in total. These were not borderline cases or false positives. Bitdefender reported backdoors, credential-stealing payloads, and information exfiltration routines disguised as useful automations. Crypto-focused skills targeting Solana and Binance users were particularly well-represented in the malicious category.

This matters because an OpenClaw skill runs with whatever permissions the AI agent has been granted. If an agent has access to a user's filesystem, messaging platforms, and API keys, so does every skill installed on that agent. The combination of public internet exposure, known RCE vulnerabilities, and a marketplace riddled with malicious plugins created what one security analysis described as a "lethal trifecta": private data access, untrusted content exposure, and external communication capability, all converging on a single platform.

The Default Configuration Problem

The root cause of the mass exposure was arguably the most mundane and most preventable element of the entire incident. OpenClaw's gateway server bound to all network interfaces by default rather than restricting connections to the local machine only. For a tool marketed as a personal AI assistant that "you run on your own devices," this default was the architectural equivalent of designing a diary with a public-access API.

Users who deployed OpenClaw without changing this default, particularly on cloud instances or machines with public IP addresses, inadvertently made their entire AI agent stack accessible to anyone who knew where to look. Many apparently did not know to look at their own network configuration, given that 135,000 of them left their instances wide open.

SecurityScorecard's STRIKE team explicitly urged immediate configuration changes and cautious organizational deployment, warning that the combination of insecure defaults and the malicious skill ecosystem made OpenClaw a high-value attack vector.

The Response

OpenClaw released version 2026.1.29, which patched all three CVEs. The project also announced a partnership with VirusTotal to scan ClawHub skills for malicious behavior before users could install them - a reasonable measure, though one that arrived after 900 malicious skills had already been distributed through the registry.

The version history tells its own story about the timeline. The CVEs were received by MITRE on February 1 and 2, 2026. NIST completed initial analysis by February 13. The SecurityScorecard scanning data landed on February 9. The patch had been available since January 29, but with 135,000 instances still exposed more than a week later, adoption was clearly not keeping pace with the threat.

What This Tells Us

The OpenClaw incident is a textbook illustration of what happens when an open-source tool designed for personal, local-first use gains mass adoption without its security posture evolving to match. The default binding to all interfaces was a convenience choice that became a liability at scale. The skill marketplace grew faster than the vetting infrastructure could support. And the CVEs turned a misconfiguration problem into an active exploitation opportunity.

For organizations evaluating AI agent deployments, the takeaway is direct: default configurations are not security configurations. An AI agent with broad system permissions, network exposure, and an unvetted plugin ecosystem is not a productivity tool. It is an attack surface dressed up in a helpful chatbot interface.