OpenClaw security fails at three levels: a CVSS 8.8 WebSocket RCE, poisoned skills on ClawHub, and fake installers exploiting search. Here is how each one works.
OpenClaw runs on your machine. It reads your files, executes shell commands, and connects to external services on your behalf. That local-execution model is the product's entire value proposition, and it is also why openclaw security failures hit harder than equivalent bugs in cloud-hosted AI tools.
A SaaS platform with a vulnerability exposes data within its own boundary. OpenClaw with the same vulnerability exposes your workstation, your credentials, and every service your machine can reach. Three confirmed attack classes demonstrate this pattern: a WebSocket hijack that grants remote code execution through a single click, a poisoned skill ecosystem where nearly one in five early submissions carried malware, and a fake-installer campaign that weaponized search engines to deliver stealers. None of these are theoretical. All have been documented, dissected, and (in some cases) patched.
OpenClaw is a locally running, high-privilege AI agent. Since its November 2025 launch, the project has crossed 149,000 GitHub stars, making it one of the fastest-growing open-source AI projects in history. It supports a public skill marketplace (ClawHub), broad system access by default, and a plugin architecture where skills are plain-language instructions interpreted by the LLM at runtime.
That combination of speed, openness, and privilege creates an attack surface unlike anything in traditional API gateways or managed AI services. When something goes wrong in OpenClaw, the blast radius is the host machine itself.
CVE-2026-25253 carries a CVSS score of 8.8. The mechanics are straightforward and worth understanding in detail, because they reveal how OpenClaw's trust model breaks down.
OpenClaw's Control UI accepts a gatewayUrl parameter from the query string. When the UI loads, it auto-connects to whatever URL that parameter specifies, sending the stored gateway authentication token in the WebSocket payload. No origin validation. No user confirmation. A crafted link or a malicious page triggers the connection in milliseconds, and the token lands on an attacker-controlled server.
The critical detail: this works even when OpenClaw is bound to localhost. The victim's own browser acts as the bridge, initiating the outbound WebSocket connection from inside the network boundary. Binding to loopback, a common "security" configuration, provides zero protection.
Once an attacker holds the token, the damage compounds. The token's privileged scopes (operator.admin and operator.approvals) let the attacker disable user confirmation by setting approval checks to "off" and force the agent to run commands directly on the host machine rather than inside Docker. The sandbox and approval guardrails that users rely on become irrelevant.
Mav Levin, founding security researcher at depthfirst, put it plainly: those defenses were designed to contain malicious LLM actions from prompt injection, not to protect against an authentication token compromise. Users who assumed the sandbox would limit blast radius were wrong.
The fix landed in version 2026.1.29. But the architectural lesson persists: OpenClaw's security model assumes the gateway token stays secret. Any future vulnerability that leaks that token reopens the same escalation path.
ClawHub is OpenClaw's public skill registry. Skills are plain-language instruction files that the LLM interprets at runtime, which means traditional static analysis has a fundamental limitation: malicious intent only manifests when the model executes the instructions, not when a scanner reads the file.
The scale of the problem is documented. Koi Security's ClawHavoc research found 341 malicious skills on ClawHub. Bitdefender Labs reported that approximately 17% of skills analyzed in the platform's first weeks carried malicious payloads. Palo Alto Networks Unit 42 identified five malicious skills falling into three distinct threat categories:
Infostealers. Trend Micro confirmed skills distributing Atomic macOS Stealer (AMOS) through the marketplace. These connect to command-and-control infrastructure and target macOS credentials.
Detection evasion. Two distinct techniques have been documented. A skill called "omnicogg" hid a malware downloader in a README file padded with junk data, designed to exceed processing limits of automated scanning systems, giving the payload cover while passing marketplace security checks. A separate skill used an inflated file size to exceed scanner thresholds, bypassing both ClawScan and VirusTotal detection.
Agentic threats. A financial advisory skill called "money-radar" weaponized the agent's advisory authority, routing all financial recommendations through affiliate links from a known-malicious domain. This is a novel category: the skill does not steal credentials or install malware. It corrupts the agent's output to generate revenue for the attacker.
Collectively, these skills enable credential theft, file exfiltration, hidden instruction injection, unauthorized action execution, and abuse of connected SaaS services. Johan Edholm, co-founder at Detectify, described the core challenge: because skills are plain language interpreted by LLMs, static checks alone cannot reliably infer malicious intent. Adding human review creates bottlenecks. Using LLMs to review skills helps but is imperfect. Like classic malware detection, it remains a cat-and-mouse game.
OpenClaw's own documentation acknowledges this. The official security guidance warns users to treat all third-party skills as untrusted code and recommends sandboxed execution for high-risk tools. Useful advice, but it shifts the security burden entirely to the user.
The third vector targets users before they even install OpenClaw. Attackers created fake OpenClaw installation projects on GitHub and used Bing's AI-enhanced search results to direct users searching for the Windows installer to malicious download sources. Users trusted the search results, trusted the GitHub platform, and downloaded malware.
Trend Micro documented a related technique: attackers disguised malicious content as OpenClaw skills, using SKILL.md instructions that appeared to be normal setup steps but actually delivered AMOS malware to macOS devices. Trend Micro described this as evidence that threat actors are using AI agents as a "trusted intermediary", packaging high-risk actions as routine installation steps.
This is the shadow AI problem in concrete form. HKCERT framed OpenClaw's risks as not simply security issues of a single application, but risks associated with a class of high-privilege AI agents. Without version management, skill review processes, least-privilege settings, endpoint protection, and continuous monitoring, platforms like OpenClaw get adopted rapidly outside formal security governance. The agent appears on developer machines before the security team knows it exists.
All three risks exploit the same set of OpenClaw design properties:
| Property | Why it exists | How it gets exploited |
|---|---|---|
| Local execution | Agent needs to act on your files and tools | Token theft escalates to host-level RCE |
| High privilege by default | Reduces friction for new users | Stolen tokens carry admin and approval scopes |
| Open skill ecosystem | Community-driven capability growth | 341 documented malicious skills, 17% early malware rate |
| Trusted intermediary status | Users follow agent instructions | Fake setup steps deliver stealers |
These are not bugs in the traditional sense. They are consequences of architectural decisions that prioritize developer velocity and openness over containment. Fixing one CVE does not change the attack surface that produced it.
OpenClaw's own guidance (treat skills as untrusted, use sandboxing) is necessary but insufficient. If the agent itself can be compromised via a single link click, the sandbox configuration is just another setting the attacker toggles off.
Effective mitigation requires controls that sit between the agent and everything it touches: gateway-level authentication that cannot be overridden by the agent's own API, runtime policy enforcement on tool invocations, skill vetting before execution, and audit logging that the agent cannot disable. This is the role of an AI gateway security layer, and it is where platforms like SHIM operate. A zero-retention gateway that enforces PII redaction, encrypts LLM traffic, and applies policy at the network boundary addresses the class of risk, not just individual CVEs.
For teams already running OpenClaw, the immediate priorities are clear: update past version 2026.1.29, audit every installed skill against ClawHavoc's published list, enforce Docker sandboxing for all tool execution, and restrict the gateway token's scope. For teams evaluating whether to deploy OpenClaw at all, the question is whether your organization has the AI agent security infrastructure to govern a high-privilege local agent, or whether a managed alternative with built-in guardrails is the more defensible choice. We covered several such alternatives to OpenClaw in a companion piece.