News

OpenClaw's plugin marketplace gained trust signals. Did moderation keep up?

July 23, 20269 min readUpdated September 13, 2026By OpenClawBlog Team

Published July 23, 2026 · OpenClawBlog Team

Installing an extension from a marketplace can look like a small decision. In OpenClaw, the choice may change what an agent can read, run, or send. The useful summer-2026 question was not whether ClawHub displayed a badge. It was whether the badge, the source record, and the moderation process gave an operator enough evidence to make a bounded decision.

By July 23, the public record supported a cautious answer. ClawHub had built several trust surfaces: publisher and source metadata, scan results, Skill Cards, stored reports, reporting and hold mechanisms, and account actions. The same record showed why those controls were not a safety certificate. Unit 42 said five malicious skills remained unblocked during a February-to-May review, while an OpenClaw Foundation and NVIDIA paper found that the scanners used in the registry rarely agreed.

The signal stack arrived in stages

The ClawHub changelog gives the clearest dated trail. On May 18, version 0.16.0 moved upload classification to a GitHub Actions Codex worker, treated VirusTotal as a telemetry signal, and added trust and popularity as search tie-breakers. On May 25, version 0.18.0 added Skill Card verification surfaces and blocked public raw files when moderation had already blocked downloads.

June filled in the operator-facing pieces. Version 0.19.0 added authenticated scan submission and polling, with ClawScan verdict fields and supporting scanner evidence. Version 0.20.0 added stored scan-report downloads for blocked submitted versions. Version 0.20.2 added local plugin validation through clawhub package validate, while version 0.21.0 added commands for GitHub Actions OIDC trusted publishing. Later June entries restored batch scanning and updated the Plugin Inspector.

The OpenClaw v2026.5.28 release record described the same direction from the client side: plugin display names, plus skill verification and trust surfaces. The editorial inference is straightforward. ClawHub was becoming a distribution system with records around identity, packaging, scanning, and recovery, rather than a simple download page. That still says nothing about detection accuracy or the behavior of every published artifact.

A trust badge is not one thing

On June 1, the project's announcement about its NVIDIA collaboration said every ClawHub skill passed a pre-catalog verification gate. The described pipeline combined static analysis, VirusTotal, NVIDIA SkillSpector, provenance, metadata, and moderation history before ClawScan produced a final result. The announcement also introduced Skill Cards showing the publisher, stated capability, origin, and scan result.

That is useful information, but the page itself described SkillSpector findings as advisories rather than automatic blocking decisions. The current security-audit documentation makes a similar distinction. It separates audit status from risk level, asks readers to inspect findings and requested credentials, and says an audit is a strong signal rather than a guarantee.

The labels also need a date. The June announcement uses Clean, Suspicious, and Malicious. The undated audit page currently uses Pass, Review, Warn, and Malicious. That difference does not by itself prove a regression or a change in policy. It does mean that a report should record the page, version, and label vocabulary instead of treating a green word as a permanent certification.

The June counterexample

Palo Alto Networks Unit 42 reported on June 23 that its analysis of ClawHub activity from February through May found five malicious skills that were still unblocked. The report described two skills delivering macOS infostealers, one using an inflated file size to bypass ClawScan and VirusTotal thresholds, and two using agentic techniques for financial gain.

Unit 42 said it reported all five to ClawHub, after which OpenClaw banned the associated accounts and deleted the skills. That is evidence of a response path working after discovery. It is also evidence that the earlier screening layers did not catch every case before publication. The report is a documented threat-research account, not a registry-wide miss rate, so it cannot tell us how common the failure was.

Moderation had a process, but not a public scorecard

The moderation documentation says signed-in users can report skills, plugins, and packages for malicious listings, misleading metadata, undeclared credentials, suspicious install instructions, impersonation, or policy violations. It separates marketplace abuse reports from vulnerabilities in a third-party project's own code, which should go to the publisher or source repository.

The documented enforcement ladder includes moderation holds, hidden or quarantined listings, blocked downloads, token revocation, publishing restrictions, and account bans. Owners may still see diagnostics for held content. The acceptable-usage policy also prohibits manipulating installs, downloads, stars, discovery, or trust signals. It says ClawHub may combine automated checks, statistical abuse signals, user reports, and staff review, while warning that a signal alone does not prove abuse.

Those are meaningful public controls. They are not public outcome measurements. In the dated records and policy pages reviewed for this article, there was no moderation table showing report volume, median response time, false-positive rate, scanner recall, or the number of blocked releases over the summer. Internal metrics may exist; the public sources do not establish them.

Skills and native plugins are not the same evidence

The ClawHub repository description covers text-based skills as well as code plugins, bundle plugins, and experimental whole-agent packages. The June changelog documents plugin validation and trusted publishing, but the most detailed public research in this record concerns skills. The 67,453-item dataset and the Unit 42 takedown should not be presented as measurements of every native plugin.

That distinction matters when an operator sees a verified publisher or a clean Skill Card. It may say something about the registry record and the submitted artifact. It does not automatically establish that a native plugin has harmless runtime behavior, safe dependencies, or a narrow authority boundary.

What an operator can check

The following are decision criteria and proposed checks, not tests run for this report.

Record the exact owner, source, package name, version, changelog, and resolved artifact. If the origin or maintainer relationship is unclear, stop before enabling it.
Read the audit status, risk level, findings, required environment variables, and permissions together. A Pass or Clean result is only one part of that record.
Compare the requested authority with the job. A document formatter that wants broad filesystem access or an automation skill that asks for undeclared credentials needs an explanation before approval.
For a native plugin, keep the validation report and test the exact version in a disposable Gateway or workspace. A trusted publishing path helps establish who released an artifact; it does not prove that the artifact is safe.
Keep a rollback point and an exact copy of the reviewed artifact. If a release becomes hidden, quarantined, pending, or blocked, do not replace it with an unreviewed version simply to restore the feature.

Failure paths and limits

A scanner can miss a semantic instruction, a delayed network action, or an evasion technique. Unit 42's file-size example is a concrete warning about threshold-based screening. The scanner-disagreement paper adds a different warning: disagreement is normal enough that a single positive or negative result cannot carry the whole decision.

The ClawHub Security Signals paper describes a sanitized snapshot of 67,453 latest public skill versions taken on May 31. It reports that 81.9 percent of flagged skills were identified by only one scanner and that only 0.69 percent were flagged by all three. The paper calls the corpus a silver-standard dataset: its labels are automated registry verdicts, not human-annotated ground truth, and the study examines scanner disagreement rather than estimating malicious-skill prevalence.

This leaves a practical boundary. A visible listing means the marketplace has not blocked it at that point in time. It does not mean the code has been independently certified. A moderation report can lead to a hold or removal, but the absence of a visible hold does not reveal how many reports were never made or how a package behaves after an update.

The answer the public record supports

As of July 23, public evidence showed ClawHub moving toward layered moderation and clearer trust signals. It showed dated work on Skill Cards, scan evidence, plugin validation, provenance, reporting, and account enforcement. It also showed the limits of that work through a reported takedown and measurable disagreement between scanners.

For a disposable, low-authority experiment, those signals make a review process possible. For an extension that can touch production files, accounts, or credentials, the safer conclusion is narrower: treat the registry entry as evidence to inspect, not permission to trust. The public record was enough to support that decision. It was not enough to declare the ecosystem safe.

Sources

Sources accessed 2026-09-13. Release and report dates are historical dates shown on the linked pages. The policy pages do not list publication dates, so they document the stated mechanisms without proving when every rule shipped.