OpenClaw 2.0: What the Biggest Rewrite Yet Changes for Skill Supply-Chain Risk

On 30 August 2026, OpenClaw shipped 2.0 - by the maintainers' own description, "by far the largest update in the history of OpenClaw." It arrived roughly ten weeks after the security crisis that made the project a case study in agentic-AI risk: a one-click RCE, tens of thousands of exposed control panels, a malicious-skill campaign, and a data leak. We covered that sequence in the OpenClaw security crisis advisory.

This advisory is about what happened next. OpenClaw 2.0 does ship real security work - masked credential prompts and per-operation approval for recurring automations - but it leaves sandboxing opt-in, and a rewrite that large does not change the architecture that made the skill supply chain attackable. Two independent research efforts, Unit 42's skill analysis and Backslash Security's risk review, show the failure modes were still live through the summer. We also publish what our own scanning shows, because the widely repeated claim that "OpenClaw skills are malicious" collapses two very different populations into one number.

Scope note. Our scan dataset was generated on 11 August 2026, which is *before* the 2.0 release. The verdict figures below therefore describe the skill corpus 2.0 inherited, not the post-2.0 state. Findings indicate risk patterns, not confirmed exploitation.

What OpenClaw 2.0 actually changed

The scale is the story. OpenClaw 2.0 landed with 933 contributors (569 of them first-time), more than 16,000 pull requests, and by the project's own accounting roughly 50% of all pull requests ever merged into OpenClaw. It touched installation, messaging, memory, skills, models, automations, the browser and native apps, plugins and security. The team went nearly seven weeks without shipping to do it - a sharp break from the previous cadence of 106 releases in 230 days.

The major version bump was not planned. The stated goal was narrower: simplify installation and rebuild the browser app.

Doing that properly meant carrying the cleanup through the rest of OpenClaw until it became OpenClaw 2.0.

That framing matters for anyone doing security review. A release that rewrites half a project's history in seven weeks, assembled largely from first-time contributors, is not a release you can diff line by line. Whatever assurance you had about OpenClaw's behaviour at 2026.1.x does not transfer automatically to 2.0, and the surfaces that were rebuilt - installation, plugins, the browser app, skills - are precisely the ones that carry security weight. Treat 2.0 as a new package requiring fresh review, not an upgrade.

What 2.0 did change for security, and what it left to you

The release announcement lists security among the areas touched but does not enumerate the changes. MyClaw's 1 September review of v2026.8.1 does. Worth noting for weighting: MyClaw sells managed OpenClaw hosting, so it has a commercial interest in self-hosting looking operationally demanding - but its specifics are checkable against the release, and the security-relevant ones are concrete:

• Masked credential prompts. OpenClaw 2.0 can request a secret through a masked prompt instead of placing it in ordinary chat or model context. An optional proxy can restrict where protected values are substituted.
• Per-operation approval for recurring work. A scheduled automation can be approved for one exact operation, and a change to the job requires a fresh approval - which closes the pattern where an approved automation quietly widens over time.
• Approvals and activity surfaced in the browser workspace. Sessions, files, approvals, terminals and browser activity now sit next to the conversation, and durable progress views survive a reload.

Those are genuine improvements, and they target the right things: secrets leaving the trust boundary, and standing authority accruing to automations. Credit where due. The limitation is the one that matters for the rest of this advisory:

Regular installs use conservative network defaults, but sandboxing is opt-in, and trusted single-operator setups can allow broad host execution without approval prompts.

Opt-in sandboxing is the same finding Unit 42 reaches from the other direction. Unit 42 attributes malicious-skill success to a lack of isolation between skill logic and agent authority; a default configuration in which sandboxing is off and a trusted single-operator setup can execute broadly on the host *is* that missing isolation, expressed as a default. Better approval surfaces help a human who is watching. They do not constrain a skill the agent has already been persuaded to run.

One more boundary is worth stating plainly, because 2.0's headline collaboration feature invites the wrong assumption. Shared sessions let work move across paired devices and cloud workers with other participants following or taking over. They are not a tenancy boundary:

Session ownership and interface permissions do not turn one Gateway into hostile multi-tenant infrastructure.

For an enterprise that reads as: do not put mutually untrusted teams, clients or environments behind one Gateway because shared sessions make it convenient. Separate customers or untrusting groups still need separate agents, separate credentials and preferably separate Gateway or host boundaries. Shared sessions are built for a person, family or already-trusting team.

What Unit 42 found still slipping through

Unit 42 analysed ClawHub between February and May 2026 and found five malicious skills that remained unblocked - notable because ClawHub had already integrated VirusTotal and ClawScan in response to the earlier campaign. Detection was in place. It did not catch these.

The five fall into three categories: two macOS infostealers delivering payloads through command-and-control infrastructure, one evasion case, and two novel agentic financial-exploitation skills. Unit 42's named examples:

These are Unit 42's findings and verdicts, cited here with attribution - not Anomity scan results. The omnicogg padding trick is the one worth internalising: it defeats scanning without any cleverness about the payload at all. If your vetting pipeline skips files above a size threshold, the threshold *is* the bypass. We have written about the same structural weakness in malicious agent skills with hidden payloads.

For historical context, Unit 42 cites Bitdefender Labs reporting in early February 2026 that roughly 17% of early OpenClaw skills contained malicious payloads, and the ClawHavoc disclosure of 341 malicious skills. The February-May window shows the problem persisting after remediation, not a single burst.

The mechanism Unit 42 identifies is architectural rather than a coding defect. Skills exploit *semantic instruction hijacking* - abusing the agent's natural-language interpretation to get around technical constraints:

The vulnerability stems from a lack of isolation between skill logic and agent authority, enabling malicious skills to reach file systems, shells and credential managers without conventional exploits.

This is why skill vetting cannot be modelled on package scanning. A malicious npm package needs code execution. A malicious skill needs only persuasive text, because the agent already holds the permissions and will act on instructions it reads. That is the same gap described in our agent skills security primer.

Backslash's risk taxonomy and the exposure figures

Backslash Security published a consolidated review on 4 June 2026, framing OpenClaw around the fact that, unlike a chatbot returning text for a human to act on, *the agent is the executor*. Its six risk classes:

• Excessive permissions and system-level access - Backslash found agents intended to reach a single folder could read the entire filesystem, including environment variables. Insecure defaults included unauthenticated local gateways and plaintext secret storage.
• Prompt injection - malicious instructions hidden in websites, email and documents that the agent reads and obeys.
• Malicious skills and plugins - marketplace payloads that reappear under new names after removal.
• Network exposure and authentication bypass - unauthenticated instances reachable from the internet, many vulnerable to RCE and full host control.
• System prompt leakage - tool names, constraints and operational logic recoverable by simple requests.
• Malware and data exfiltration - one-click RCE chains that hijack agent connections and steal tokens and API keys.

The supporting numbers, with their sources, so they can be weighed rather than repeated:

Note that BitSight's 30,000+ is a different measurement from the figures in our June advisory (Censys ~21,639 in January, ~63,070 in late March; SecurityScorecard 40,000+ then ~135,000). Different scanners, fingerprints and dates produce different counts. The trend - a large, persistent population of unauthenticated instances - is the durable finding; any single number is not.

What our own scans show: official skills versus the ecosystem

"OpenClaw skills are dangerous" is too coarse to act on. Our Skill Risk Index lets us separate the skills the OpenClaw project publishes from third-party repositories that build on it. Method: skills whose source repository is github.com/openclaw/* are counted as official; skills in other repositories whose repository or name references OpenClaw are counted as third-party. Dataset generated 11 August 2026.

Two things follow, and the second is the one usually reported wrongly.

First, the official skills are unremarkable. All 117 come from the main openclaw/openclaw repository, none carry a critical or high verdict, and their 12.0% non-clean rate sits marginally *below* the 12.9% baseline across all 20,427 scanned skills. Whatever the ecosystem's problems, the project's own published skills are not an outlier.

Second, the 32.7% third-party figure is concentrated, not representative. Only 16 distinct third-party repositories are involved, and 2,524 of the 2,563 skills - 98.5% - come from a single aggregator repository. All 7 critical and high verdicts trace to that one author. So the number is a statement about one large repository, not evidence that the OpenClaw ecosystem is broadly three times riskier. We are publishing the caveat alongside the figure because the figure without the caveat is misleading, and a false risk claim about named third-party code is a real harm.

The practical lesson is about provenance, not platforms. One prolific publisher can dominate a marketplace's risk profile, which is exactly the shape of problem that skilljacking exploits: aggregate trust in a namespace, not in the code.

Why marketplace scanning keeps failing

ClawHub added VirusTotal and ClawScan and still shipped five malicious skills over four months. That is not a story about a weak scanner; it is three structural gaps that any skill marketplace shares:

1. Scanners look for malware; skills carry instructions. A skill whose payload is persuasive prose has no signature to match. Semantic instruction hijacking is invisible to file-reputation tooling.
2. Thresholds are bypasses. Padding a file to 22 MB defeated the pipeline outright. Any skip rule - size, file type, depth - is published attack surface.
3. Scan time is not run time. A clean scan describes a snapshot. Skills update, fetch remote content, and reappear under new names after takedown, and the agent's authority at run time is what actually gets abused.

This is why we treat scan-time vetting as necessary but not sufficient, and why the NVIDIA SkillSpector class of static analysis belongs in a pipeline that also watches behaviour. Vetting decides what may be installed; only runtime governance sees what a skill does once it holds the agent's permissions.

What to do

1. Treat 2.0 as a migration, not a patch. Prior approval of a 2026.1.x build does not survive a rewrite this size, and v2026.8.1 has concrete breaking changes: the bundled OpenProse plugin and /prose command are removed, older Codex and OpenAI model references migrate toward openai/* routes, some plugin SDK changes are required, and SQLite-backed session storage makes rollback harder. Start with openclaw update --dry-run, verify a restorable backup, then openclaw doctor --fix, restart the Gateway and run openclaw health. For a production Gateway, the extended-stable channel is a defensible place to wait.
2. Inventory instances, skills and tokens before hardening anything. Every figure in this advisory - exposed instances, malicious skills, leaked prompts - is a discovery failure first. You cannot scope the risk without knowing where OpenClaw runs, which skills it loaded, and what credentials it holds.
3. Judge skills by provenance, then by content. Our own data shows one publisher can dominate a marketplace's risk profile. Pin skills to a specific repository and commit, and re-review on change rather than trusting a namespace.
4. Assume your size and type thresholds are known to attackers. Audit what your vetting pipeline skips, and treat a skipped file as unvetted rather than clean. Our vetting and approving AI agent skills playbook covers the decision path.
5. Turn sandboxing on, because it is opt-in. This is the single highest-value configuration change in 2.0. Audit any trusted single-operator setup that can execute broadly on the host without approval prompts, and do not rely on shared sessions as a tenancy boundary - untrusted groups need separate agents, credentials and Gateway or host boundaries.
6. Constrain authority, not just installation. Because skills inherit agent permissions, least privilege at the agent level is what limits blast radius. Unauthenticated local gateways and plaintext secrets are the defaults worth checking first.
7. Monitor outbound traffic against documentation. Unit 42's recommendation, and the most reliable signal for the infostealer class: connections to endpoints the skill never documented.

OpenClaw 2.0 is a genuine engineering achievement and, on the evidence of our own scans, the project's own skills are not the problem. The problem is that a markdown file can inherit an agent's shell, filesystem and credentials, and that no marketplace scan can tell you what it will do with them. That gap does not close with a version bump.

Anomity discovers every AI agent, skill, MCP server and plugin running across your endpoints and browsers - including the OpenClaw instances nobody registered - and governs what they do at runtime. Book a 30-minute demo to see your own inventory.