OpenClaw reached 60,000 GitHub stars in under 72 hours. This pace is remarkable even by open-source standards. The tool promises to connect autonomous AI agents with local files, messaging apps, and arbitrary automation workflows. At the same time, security advisories keep piling up: five critical CVEs, over 40,000 exposed instances, and coordinated supply-chain attacks through its own marketplace. The picture is considerably more complicated than the initial hype suggests.
What Is OpenClaw?
OpenClaw is a self-hosted, autonomous AI assistant. Austrian developer Peter Steinberger launched the project in November 2025 under the name “Clawdbot”. After a trademark dispute with Anthropic, which forced a brief rename to “Moltbot”, the project has been running as OpenClaw since January 30, 2026.
The core idea is simple: AI models aren’t operated as isolated chat interfaces. They’re connected to real resources (local file systems, messaging services like WhatsApp and Discord, and arbitrary automation workflows). Agents can autonomously plan tasks, read and write files, send messages, and execute code.
In February 2026, Steinberger joined OpenAI. The project was handed over to an open-source foundation and has since been maintained by the community.
That explains part of the hype: OpenClaw addresses a genuine need. Anyone wanting to run autonomous agents locally, without sending data to external cloud services, gets a functional and extensible foundation here. We cover similar requirements in detail in our article on AI Agents in the Enterprise.
What OpenClaw Can Do Technically
OpenClaw’s architecture consists of three layers. OpenClaw supports various LLM backends, from OpenAI-compatible APIs to locally running models via Ollama or LM Studio. Configuration is handled through a central config.yaml. Through a plugin system called “Skills”, external services and local resources can be connected. The ClawHub Marketplace offers ready-made Skills for common use cases including file operations, calendar integration, and webhooks.
The core is an iterative execution loop: the agent plans steps, executes them, evaluates results, and adjusts the plan. The behavior is similar to what frameworks like LangGraph or AutoGen offer, but runs as a single self-hosted service without external dependencies.
# Example: config.yaml
agent:
model: "gpt-4o"
system_prompt: "You are an autonomous assistant for..."
tools:
- filesystem
- discord
- calendar
max_iterations: 20
token_budget: 50000For developers and small teams who want to spin up an autonomous solution quickly, this is technically attractive. The barrier to entry is low, and the documentation is well-maintained.
The Security Situation: Five Critical CVEs
With rapid growth came the vulnerabilities. Within weeks of the initial spike, five critical CVEs were published:
| CVE | Type | CVSS |
|---|---|---|
| CVE-2026-25253 | Token Leakage via Gateway URLs | 9.1 |
| CVE-2026-24763 | Remote Command Injection | 9.8 |
| CVE-2026-26322 | Server-Side Request Forgery (SSRF) | 8.6 |
| CVE-2026-26329 | Local File Exposure (Path Traversal) | 8.2 |
| CVE-2026-30741 | Code Execution via Prompt Injection | 9.3 |
CVE-2026-24763 and CVE-2026-30741 are particularly critical. Remote Command Injection allows attackers to execute arbitrary commands on the host system through crafted inputs. The Prompt Injection vulnerability is even more insidious. An attacker can use manipulated documents or messages to instruct the agent to execute commands without any direct system access.
Security researchers at CERT/CC published an analysis in mid-February 2026 showing: 40,000+ publicly reachable OpenClaw instances were identified. Between 35% and 63% run on unpatched versions. 12,812 instances are considered vulnerable to Remote Code Execution.
Supply-Chain Attacks Through the Marketplace
Beyond the core CVEs, there’s a structural problem: the ClawHub Marketplace.
Between 341 and 824 documented malicious Skills were uploaded to the marketplace. Numbers vary depending on when the data was collected, because the foundation actively removes them. The “ClawHavoc” campaign is particularly well-documented. Attackers published Skills under legitimate-sounding names (“calendar-sync”, “file-organizer”, “backup-util”) that silently extracted API tokens and sent them to external servers.
This isn’t an OpenClaw-specific problem. Similar attacks have targeted npm, PyPI, and the VS Code Extension Marketplace. But the combination of broad permissions (agents frequently have filesystem and network access) and a low-friction marketplace makes OpenClaw a particularly attractive target.
Enterprise Risks: Shadow IT and Token Management
For organizations, the technical security situation is only part of the problem. The bigger risk factor is uncontrolled adoption. OpenClaw can be set up in minutes. Developers and power users install it on personal machines or private VMs, often without the knowledge of the IT department. The result: AI agents with access to company resources running outside any security monitoring.
OpenClaw stores API tokens and credentials in a local configuration file without encryption. In the default configuration, these tokens sit in plaintext in ~/.openclaw/config.yaml. Anyone connecting the tool to corporate APIs (internal REST services, Confluence, Jira) is leaving those credentials unprotected.
Agents that access company files and invoke external services also operate in a regulatory gray area. Which data flows over which connections? Are GDPR-relevant records (the EU’s data protection regulation) being sent to external LLM APIs? Without policy oversight, there’s no way to answer that. This applies equally to teams operating under HIPAA, SOC 2, or any internal data classification policy.
This is a pattern we see repeatedly with automation tools. The answer isn’t a blanket ban. It’s clear governance structures, much like the approach we describe for managing technical debt systematically. Understand the problem first, then address it in a controlled way.
Conclusion: Potential Yes, But With Governance
OpenClaw demonstrates just how significant the demand for self-hosted, autonomous agents is. The architecture is solid, the community active, and the approach solves a genuine problem: connecting AI locally to real resources.
At the same time, the current security posture is not production-ready without active countermeasures. All five CVEs have patches that need to be applied, with CVE-2026-24763 and CVE-2026-30741 being critical enough to warrant taking unpatched instances offline immediately.
Every external Skill should have its source code reviewed before deployment. Automated dependency scans help but aren’t sufficient on their own. Credentials belong in a secrets management system like HashiCorp Vault or AWS Secrets Manager, not in a plaintext config file. A network scan for OpenClaw’s default port (8742) will reveal whether the tool is already running uncontrolled in your environment.
Before rollout begins, establish a clear governance framework addressing who is allowed to use OpenClaw, with what permissions, and which data can flow through agents. These questions need answers before adoption spreads, not after.
OpenClaw will continue to evolve. The foundation has acknowledged the security issues and is working on structural fixes. Anyone evaluating the tool in an enterprise context should treat the current state as a starting point. Run a controlled pilot before allowing broad adoption.
There is also an accompanying video on our YouTube channel.
If you’re evaluating OpenClaw or comparable agent frameworks in your organization and need support with architecture, security review, or governance design, get in touch →
Frequently Asked Questions
What is OpenClaw and why did it gain popularity so quickly?
OpenClaw is a self-hosted autonomous AI assistant that connects to local files, messaging apps, and automation workflows without cloud dependencies. It reached 60,000 GitHub stars in 72 hours because it addresses genuine demand for local, privacy-preserving AI agent deployments that teams can control independently.
How many critical vulnerabilities has OpenClaw had?
Five critical CVEs were published within weeks of launch. CVE-2026-24763 allows remote command injection with a 9.8 CVSS score. CVE-2026-30741 enables code execution via prompt injection with a 9.3 score. Research found 40,000 publicly reachable instances, with 12,812 vulnerable to remote code execution.
What is the CanisterWorm and how does it spread?
CanisterWorm is a self-propagating worm that uses stolen npm tokens from CI runners to infect npm packages. It polls Internet Computer Protocol canisters for payloads every 50 minutes and automatically infects accessible packages. The worm spread across 141 malicious artifacts in 66 packages.
How does OpenClaw store credentials and what are the risks?
OpenClaw stores API tokens and credentials in plaintext in the default configuration at ~/.openclaw/config.yaml without encryption. This exposes corporate API tokens to anyone with filesystem access. The risk increases significantly when agents access company files and invoke external services outside governance oversight.
What security measures should teams implement before deploying OpenClaw?
Rotate credentials immediately if exposed. Pin OpenClaw versions strictly and apply all security patches. Review external Skill source code before deployment. Store credentials in a secrets management system like HashiCorp Vault instead of plaintext files. Establish governance policies on who can use OpenClaw and which data flows through agents.
