Is OpenClaw Safe? Risks, CVEs & Hardening

OpenClaw is not safe in its default configuration. It has 48 confirmed CVEs, including a CVSS 9.9 authentication bypass and a one-click remote code execution flaw (CVSS 8.8), and a skill ecosystem where 86% of the 2,354 most popular OpenClaw skills we tested carry real vulnerabilities and 4.4% are outright malicious. Whether it is safe enough for your specific deployment depends on your use case, your network environment, and whether you have applied the available hardening controls.

That is the headline number. The more useful finding sits underneath it: the dominant risks are not the exotic ones. Most coverage of OpenClaw fixates on prompt injection. The measured data points somewhere more mundane. Credential and token mismanagement and vulnerabilities that nobody ever remediates account for far more real exposure than any clever injection payload. The relevant decision is whether OpenClaw is safe in your deployment context (personal use, team deployment, or enterprise), and each context carries a different risk profile and a different control set.

What the Data Actually Says

A behavioral scan of the 2,354 most popular ClawHub skills returns a split that reframes the whole conversation. Only 9.6% came back benign. 86% carried real vulnerabilities: missing input validation, unscoped permissions, plaintext credentials, unverified external endpoints. 4.4% were outright malicious. The supply chain is not overrun with attackers. It is overrun with insecure code that ships, gets installed, and never gets fixed.

This is why the scanner you use determines the answer you get. On the same 2,354 skills, signature-based scanning and behavioral analysis disagree on 89.5% of packages: behavioral analysis finds 4.4% genuinely hostile and 86% merely insecure, while the signature view classifies the same packages completely differently. At registry scale the gap is just as stark. Across the full 52,652 packages, only 22% come back VirusTotal-clean. Signature tools produce false alarms and blind spots at the same time. They cannot read a prompt, and most skills ship configuration rather than recognizable malware, so the signature has nothing to match against. To be fair, ClawHub tries. The registry runs VirusTotal on submissions. The problem is the wrong tool for the job, not negligence: a signature scanner answers “does this match known malware,” when the question that matters is “what will this skill do when it runs.”

OWASP ranks token mismanagement (MCP01) as the single largest risk in its MCP Top 10, ahead of tool poisoning. That tracks with what behavioral scanning finds inside ClawHub: plaintext credentials and unscoped permissions are everywhere, and a skill holding a long-lived token is a more reliable path to compromise than any prompt injection campaign.

What Makes OpenClaw Risky

OpenClaw’s risk profile has four distinct sources: its architecture, its vulnerability record, its supply chain ecosystem, and its real-world exposure. Each layer compounds the next. Architecture defines the attack surface; CVEs demonstrate exploitability; the supply chain expands entry points, and exposure determines whether those risks are actively exploited.

1. Architectural risk. Natural language interface, persistent memory, and extensibility create a structural attack surface independent of implementation bugs.
2. CVE vulnerability record. 48 confirmed CVEs as of June 2026, including multiple CVSS 9.9 and 8.8 findings.
3. Supply chain risk. Our scan of the 2,354 most popular skills on ClawHub found 86% vulnerable and 4.4% malicious. Signature-based scanners disagree with behavioral analysis on 89.5% of packages.
4. Deployment exposure. Default config binds the gateway to 0.0.0.0 without authentication. Any exposed instance is one credential-harvesting skill away from persistent access.

The Architecture Problem

OpenClaw’s risk profile is not primarily the result of implementation bugs. It is a consequence of the architecture: a natural language interface connected to the local file system, network, and application layer, with persistent memory across sessions. Any tool with that combination of access and that level of extensibility will have a large attack surface. The question is whether the security controls match the capability.

Three architectural properties compound the risk: natural language as an input channel without type-safe validation, persistent memory that allows cross-session state manipulation, and extensibility through skills that introduce a distributed and difficult-to-verify execution layer.

Prompt injection lives here, and it is real. It is also not where the measured exposure concentrates. Runtime LLM guardrails can reduce the prompt injection surface, but they cannot eliminate it, and they do nothing about the plaintext token a skill copied into a config file three weeks ago. Spend your attention where the data points: credentials, permissions, and the vulnerabilities sitting unpatched in skills you already trust.

The Vulnerability Record

As of June 2026, OpenClaw has 48 confirmed CVEs and more than 138 total security advisories once GitHub Security Advisories awaiting CVE IDs are included. The most severe include CVE-2026-22172 (CVSS 9.9, WebSocket authorization bypass allowing a remote attacker to self-declare admin status), CVE-2026-25253 (CVSS 8.8, one-click RCE via WebSocket token exfiltration), CVE-2026-32042 (CVSS 8.8, privilege escalation via an unpaired device), and the May 2026 “Claw Chain” set (CVE-2026-44112 through 44118, CVSS up to 9.6, a sandbox-escape and privilege-escalation chain confirmed exploited in the wild and patched in version 2026.4.22).

OpenClaw has responded to disclosures with patches, but the pace of new CVEs suggests the underlying attack surface continues to grow as feature development outpaces security review. For a system with direct file system and network access, that trend should factor into your risk assessment.

The Supply Chain Problem

We ran a behavioral security analysis on the 2,354 most popular OpenClaw skills on ClawHub and compared the findings against VirusTotal. Only 9.6% came back benign. 86% carried real vulnerabilities (missing input validation, unscoped permissions, plaintext credentials, unverified external endpoints), and 4.4% were outright malicious. The two tools disagreed on 89.5% of packages, meaning signature-based scanners alone cannot tell you whether a skill is safe. ClawHub skill ecosystem risk is the equivalent of an npm registry with no mandatory security scanning: a single installed skill can give an attacker persistent access to every system OpenClaw can reach. Full methodology and breakdown: Trent’s ClawHub security analysis.

Skills that interact with OpenClaw’s memory or retrieval layers introduce the same RAG security concerns that affect any agent with access to a persistent knowledge store. Every installed skill becomes part of the effective attack surface.

The Exposure Problem

Self-hosted OpenClaw instances routinely end up exposed to the public internet when operators leave the gateway bound to 0.0.0.0 instead of 127.0.0.1 or skip authentication on the default configuration. That exposure is not theoretical. Once the gateway is reachable, any installed skill that auto-pushes data, harvests credentials, or calls unverified external endpoints (per the 86% vulnerable / 4.4% malicious split from Trent’s ClawHub scan) becomes a persistent access path into the host.

Malware families targeting AI-tool configuration files have been observed extracting OpenClaw config data from exposed instances. Treat the gateway binding as the first control to verify any deployment.

What OpenClaw’s Developers Have Fixed

OpenClaw’s developers have responded to sustained security criticism with meaningful engineering changes. Since early 2026, the project has introduced a formal threat model, added pre-installation scanning controls for marketplace content, and hardened several authentication pathways tied to high-severity disclosures.

Since January 2026, OpenClaw’s developers have released a formal threat model mapping 37 identified threats against MITRE ATLAS, VirusTotal integration for skill scanning before installation, and gateway authentication hardening that closes several of the authorization bypass vulnerabilities. The patches for CVE-2026-22172 and CVE-2026-25253 are available, please apply them now if you haven’t already. This is a genuine security investment, not a checkbox exercise.

More recently, the project shifted from prevention to containment: the 2026.4.14 release locked down runtime config mutation (config.patch) and isolated auto-reply context by sender, so a low-privilege message can no longer execute with an operator’s permissions. Subsequent May 2026 releases tightened input validation and exposure defaults further.

Whether you have applied these updates is the first thing to verify if you are currently running OpenClaw.

What remains are risks that are not reducible to patching. Prompt injection is not a discrete bug but a property of the interaction model. When natural language is the control surface for tool execution, input validation cannot be made deterministic. Runtime LLM guardrails can reduce the prompt injection surface, but they cannot eliminate it.

Patches fix implementation bugs. Architecture determines what bugs are possible.

OpenClaw’s architecture, i.e. persistent memory, tool access, and extensibility, means new vulnerability classes will continue to emerge even as known CVEs are remediated. The growth in capabilities directly increases the number of reachable states an attacker can influence. That makes OpenClaw representative of agentic systems where execution is driven by probabilistic interpretation rather than deterministic input validation. Your decision is not whether OpenClaw can be made risk-free. It is whether your environment can absorb the residual risk after hardening.

Risk Assessment by Use Case

OpenClaw’s risk profile varies significantly by deployment context. For personal or home lab use with network isolation and verified skills, the risk is moderate and manageable. For startup or small-team deployments with production system access, the risk is high and requires formal policy and hardening. For enterprise deployments with regulatory exposure and customer data in scope, the risk is very high. Formal security evaluation is required before deployment, not after.

The three variables that determine risk are network exposure, credential scope, and organizational blast radius.

The enterprise row is not hypothetical. Several large engineering organizations and government bodies have restricted or formally evaluated AI coding agents with comparable access profiles. The reasons are the same three you see with OpenClaw: credential scope, supply-chain risk, and audit gap.

Personal / Home Lab Use

For personal deployments, risk is moderate and mostly comes down to configuration choices. The dominant failure mode is unintended exposure, either through network access or credential scope.

Bind OpenClaw to localhost only and avoid exposing it to the internet. Don’t provide cloud provider credentials, production API keys, or SSH access within the environment it can reach. Treat skill installation as arbitrary code execution with filesystem access, not as a benign extension mechanism.

This mirrors what self-hosters already do in practice: run it on a dedicated machine with no personal or company data, accessed over a separate channel.

If you are running OpenClaw locally with these controls in place, your residual risk is comparable to other developer tools with network and filesystem access.

Startup / Small Team

At the team level, risk increases because compromise propagates across shared systems. A single malicious skill or prompt injection event can affect every system the deployment can reach, including CI/CD pipelines and production services.

If your team is using OpenClaw against production systems, you need a written security policy before the next skill install happens. Restrict skills to a verified publisher allowlist, implement network egress controls, and assign ownership for patch management.

Enterprise

Enterprise deployment introduces regulatory, legal, and audit constraints that change the risk calculation. The primary concern is not only compromise but the scope of impact: customer data, internal systems, and compliance obligations.

Treat OpenClaw as a third-party system with privileged access. That means formal procurement review, legal approval, sandboxed deployment environments, and continuous monitoring of agent behavior and tool access.

A responsible enterprise deployment assumes new vulnerabilities will continue to emerge.

Major vendors are simultaneously warning against OpenClaw and building on it. That is not a contradiction: it means OpenClaw is viable under isolation and governance, not safe by default. The enterprise question is whether you can enforce those controls.

OpenClaw Hardening Checklist

Before You Install

Start with a threat model of your environment. Identify exactly which file systems, credentials, APIs, and network segments OpenClaw will be able to access. If you cannot describe that scope precisely, don’t install it yet.

Define your network configuration before deployment. Decide whether OpenClaw will run localhost-only or require remote access. If remote access is required, define which ports are exposed and from which source IP ranges.

Scope credentials explicitly. Create dedicated API keys or service accounts with minimum required permissions. Never use your primary credentials or grant access to production systems without isolation.

If You’re Already Running It

First, verify your version and patch status. CVE-2026-22172 (CVSS 9.9) and CVE-2026-25253 (CVSS 8.8) have patches available and should be applied immediately if you have not done so.

Audit every installed skill. Scan each one against Trent’s ClawHub safety baseline. Remove any skill the behavioral analysis flagged as malicious. Skills that are flagged as vulnerable need a hardening pass before they stay in production.

Check your network exposure. Determine whether your OpenClaw instance is accessible outside localhost. If it is, confirm whether that exposure is required and enforce authentication controls if it must remain open.

If Your Organization Needs a Policy

Define approved deployment contexts. Specify whether OpenClaw is allowed in personal development environments, staging systems, or production infrastructure.

Establish skills governance. Define which publishers are approved, who can approve new skills, and how skill updates are reviewed before installation.

Set a patch SLA. Given the pace of new CVEs, your organization should require patching within 72 hours for Critical and High vulnerabilities.

The Bigger Question

OpenClaw is not uniquely dangerous among agentic AI tools. It is one of the first to reach large-scale adoption, which means it is also one of the first to be tested at scale by both researchers and attackers. The volume of CVEs and the supply chain findings reflect scrutiny proportional to deployment, not a fundamentally different risk category. Any system that combines natural language control, persistent memory, and tool execution will expose similar classes of vulnerabilities.

The framework for analyzing these systems is agentic AI security, a discipline that exists because traditional application security models do not map cleanly to autonomous, tool-using systems.

The question is not whether OpenClaw is safe. The question is whether your environment can safely support any agentic system with comparable access and autonomy.

Continuous monitoring of agentic AI deployments, flagging when an agent’s tool access or behavior exceeds expected scope, is what the Trent AI platform provides across any agentic tool, not just OpenClaw. For OpenClaw-specific coverage, the trentclaw skill is the starting point.

Reviewed by Eno Thereska, Co-founder & CEO at Trent AI