🆕 We pulled metadata on all 52,652 ClawHub packages. Only 22% are "clean".

OpenClaw Security: The Complete Map of Risk, CVEs, and Supply Chain

Trent AI Team
By Trent AI Team
Jul 2026 • 8 min read

Four numbers define OpenClaw’s security position as of June 2026: 48 confirmed CVEs, a default gateway that binds to 0.0.0.0 with no authentication, a skill registry of 52,652 packages, and a behavioral scan of the 2,354 most popular of those skills that came back 86% vulnerable and 4.4% malicious. Each number maps to a different layer of the same system. None of them is the whole story, and none of them is a configuration line you can flip off.

Search for “OpenClaw security” and you will find the same article forty times: a ten-step checklist promising a hardened instance in thirty minutes. Those checklists are not wrong. They are incomplete because they treat OpenClaw as a misconfiguration problem, when most of the risk is structural. The gateway binding is a setting; the architecture, the CVE pace, and the supply chain are not.

This Is the Map

It covers the four layers where OpenClaw security actually lives, leads each with a measured number, and routes to the deeper analysis where we have original data. If you want the risk-by-use-case decision, that lives in our article exploring if OpenClaw is safe. If you want the full registry breakdown, that lives in our ClawHub security analysis article. The current article is the layer above both: what the surface is, why it exists, and where to look next.

The Four Layers of OpenClaw Security

OpenClaw’s risk is not one problem but four, and they stack: architecture defines the attack surface, the CVE record proves that surface is reachable, the supply chain multiplies the entry points, and deployment exposure decides whether any of it gets exploited.

Layer Measured signal What it tells you
Architecture Natural language control surface + persistent memory + tool access The surface exists by design, not by bug
Vulnerability record 48 confirmed CVEs, top two at CVSS 9.9 and 8.8 The surface is reachable and actively researched
Supply chain 86% of 2,354 scanned skills vulnerable, 4.4% malicious Every installed skill extends the attack surface
Deployment exposure Gateway binds 0.0.0.0, no auth, by default The first three layers become live the moment you expose the port

Layer 1: Architecture Is the Attack Surface

The defining property of OpenClaw is that natural language drives tool execution against the local file system, the network, and the application layer, with memory that persists across sessions. That is the source of the risk, and no patch removes it.

Traditional application security assumes you can validate input deterministically. You define a type, you check it, you reject what does not match. OpenClaw breaks that assumption at the root. When the control surface is natural language, there is no type to enforce. The model interprets intent probabilistically, and an attacker who can shape the input can shape the interpretation. This is why prompt injection is not a discrete vulnerability with a fix version; it is a property of the interaction model.

Three architectural properties compound. Natural language as an input channel has no type-safe boundary. Persistent memory allows state planted in one session to influence a later one. Extensibility through skills introduces a distributed execution layer that is difficult to verify. The code quality across these skills is often fine. The architecture is what separates a safe deployment from a compromised one.

If you want the vocabulary for reasoning about this layer, agentic AI security terminology defines the terms precisely, and runtime LLM guardrails are the control class that reduces the prompt injection surface without claiming to eliminate it. Nothing eliminates it. That is the point of starting here.

Layer 2: The CVE Record

OpenClaw has 48 confirmed CVEs as of June 2026. The two that matter most are CVE-2026-22172, a WebSocket authentication bypass rated CVSS 9.9 that lets a remote attacker self-declare admin status, and CVE-2026-25253, a one-click remote code execution path rated CVSS 8.8. Patches exist for both. If you run OpenClaw and have not applied them, that is the first thing to fix, before you read further.

The count is not the signal; the slope is. A vulnerability record that keeps growing as features ship tells you the attack surface is expanding faster than security review can cover it. For a system with direct file system and network access, that trend belongs in your risk assessment more than any single CVSS score does.

OpenClaw’s developers have responded with real engineering: a formal threat model, pre-installation scanning for marketplace content, and authentication hardening tied to the high-severity disclosures. This is a genuine investment, not a checkbox. It also does not change Layer 1. Patches close implementation bugs. Architecture decides which bugs are possible, and a probabilistic control surface will keep producing new vulnerability classes as capability grows.

Layer 3: The Supply Chain (Where We Have the Data)

This is the layer most checklists skip, and it is the one where signature scanning fails hardest. We ran behavioral analysis on the 2,354 most popular skills on ClawHub. 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 number that should change how you scan: signature-based detection and behavioral analysis disagreed on 89.5% of packages. Run a skill through a signature scanner, and it comes back clean. Run the same skill through behavioral analysis, and it reaches for credentials it has no reason to touch. Both results are real, but they measure different things, and the one most teams rely on is the one that misses the most. A single installed skill can hand an attacker persistent access to every system OpenClaw can reach.

The registry holds 52,652 packages. The 2,354 we scanned are the popular tail, the ones most likely to be installed. The full methodology, the named attack patterns, and the per-category breakdown live in our ClawHub security analysis, and the registry-wide numbers live in ClawHub by the numbers. The short version for this map: the OpenClaw skill ecosystem is an open package registry with no mandatory security scanning, and the install command is one line.

This is not a story about attackers flooding the registry. The supply chain is not overrun with malice. It is overrun with developers who shipped working tools with preventable gaps, in an ecosystem that makes skipping the controls the path of least resistance and gives no feedback when you do. Both things are true at once: a small malicious fraction, and a large vulnerable majority. The first needs removal, and the second needs a baseline.

Layer 4: Deployment Exposure

The default gateway binds to 0.0.0.0 with no authentication. That is the setting that turns the first three layers from latent into live. Bound to 127.0.0.1, an OpenClaw instance is reachable only from the host. Bound to 0.0.0.0 on a machine with a public route, it is reachable from the internet, and any installed skill that harvests credentials or calls an unverified endpoint becomes a standing access path into the host.

Exposure at scale is documented. Third-party scans have reported on the order of 42,000 OpenClaw instances exposed to the public internet, and malware families targeting AI-tool configuration files have been observed pulling OpenClaw config data from reachable hosts. Treat the gateway binding as the first control to verify on any deployment, and treat every installed skill as code running with whatever access the host grants.

The fix for this layer is the one item every checklist gets right: bind to 127.0.0.1, expose a port only when you have a verified reason, and require authentication on any instance that must stay reachable.

How the Layers Stack

The four layers are not separate risks. They are one risk at four resolutions, which is why a thirty-minute checklist gives a false sense of completion. Closing the gateway binding fixes Layer 4 and does nothing for the skill you installed last week that reads your environment variables and posts them to an endpoint you never reviewed.

Where Continuous Assessment Fits

Every control on a checklist is a point-in-time check. You harden the gateway today. Next week you install three new skills; the project ships a feature that widens tool scope, and a new CVE lands. The hardened state decays, and a one-time audit cannot see the decay.

This is the gap Trent AI is built for. The Trent AI platform runs a continuous behavioral assessment that follows a single arc, Scan to Judge to Mitigate to Evaluate: it observes what the system and its installed skills actually do, prioritizes the findings that carry real blast radius over the noise, proposes remediations you review before applying, and tracks whether the posture is improving run over run. Each run starts from what the last one already knew, so the project gets more secure over time instead of resetting to zero at every audit. The distinctive thing is not a single scan. It is that the assessment never stops and never forgets.

For OpenClaw specifically, the entry point is the trentclaw skill. It is self-serve: create a Trent account, generate an API key, and install it.

openclaw skills install @trent-ai-release/trentclaw

There is no separate dashboard to learn and no waitlist to clear. The findings render inside OpenClaw, where you already work, so a flagged skill or an over-scoped permission shows up in the same place you installed it.

What to Do With This Map

If you are running OpenClaw right now, the order is fixed by the layers. Patch CVE-2026-22172 and CVE-2026-25253 first. Verify your gateway is bound to 127.0.0.1 and not 0.0.0.0. Then audit every installed skill, because Layer 3 is the one you cannot see by reading a config file. You need a behavioral check, not a signature scan, and you need it on a schedule rather than once.

OpenClaw is not uniquely dangerous. It is one of the first agentic tools to reach this scale, which means it is one of the first tested at scale by both researchers and attackers. The volume of CVEs and the supply chain findings reflect scrutiny proportional to adoption, not a different risk category. Any system that puts natural language in control of tool execution, keeps memory across sessions, and accepts third-party extensions will expose these same four layers. The map you just read is the OpenClaw instance of a problem every agentic system is about to have.

Audit Your OpenClaw Setup

Install the trentclaw skill, run your first behavioral audit in two minutes, see the findings inside OpenClaw.

openclaw skills install @trent-ai-release/trentclaw

Install trentclaw →   See the source on GitHub

Reviewed by Zack Rossman Head of Engineering at Trent AI