23 ClawHub plugins squat the official scopes on the registry: a case study in enforcing organizational scope and namespacing on AI asset registries.
TL;DR
Manifold Security identified 23 code-executing ClawHub plugins published under ClawHub's
@openclaw/and@clawhub/scopes by accounts that have nothing to do with either organization.
ClawHub had documented the rule but did not comprehensively enforce it: a plugin's scope is supposed to match its owner, but the org scopes would accept anyone, which is a supply chain attack risk.
557 of the 1,508 plugins carry an
@owner/scope, but not all have ClawHub verified ownership.ClawHub uses the
@openclaw/scope for its own genuine plugins(@openclaw/whatsapp,@openclaw/codex), so unauthorized ones sitting under it (@openclaw/security-gate,@openclaw/fiat-wallet,@clawhub/aisa-twitter-api) inherit the same first-party credibility, for code that runs inside your agent with real privileges.We reported it to ClawHub on June 17. Following our private report, ClawHub added a procedure to dispute organizational scopes and namespaces squatted by unauthorized entities or threat actors, and unlisted the misleading plugins.
Scopes have existed for years across several registries including npm, often used to group packages and artifacts under official organizational or developer accounts and signal to consumers that scoped artifacts can be consumed with high trust, given they are coming from the official source.
If you have spent any time as an npm developer or around open source supply chain security, you already know about scoped packages and namespacing.
A scope is the @owner/ prefix on a package name. It ties a package to an owner, so consumers can tell at a glance who published it. The point is provenance: the scope is a trust signal about where the code came from.
For example, the npm package @microsoft/microsoft-graph-client sits under the @microsoft scope, owned by the company. A developer pulling that package can be reasonably confident the artifact comes from Microsoft, because npm enforces org scopes: only members of the @microsoft org can publish under it, and a non-member is rejected outright.
Enter ClawHub
ClawHub's plugins use the same model.
ClawHub is the plugin and skill registry for OpenClaw, and its skills and Claude-compatible plugin bundles install into Claude Code and other agents (Cursor, Codex) too. As of today it indexes 1,500+ plugins alongside its Skills catalog.
Plugins can be named npm-style, @owner/package-name, and the scope is meant to identify the publishing owner.
ClawHub publishes its own official plugins under these scopes too: @openclaw/whatsapp, @openclaw/codex, and @openclaw/matrix are genuine first-party integrations owned by the OpenClaw account. That trust is the whole point of the scope, and the whole problem when an unaffiliated package wears the same @openclaw/ prefix.
By contrast, other Claude plugin registries such as claude-plugins.dev derive the owner straight from the GitHub repo, so there's no separate scope for the registry itself to police — GitHub already enforces who can publish under that account. That design sidesteps the problem entirely.
ClawHub, having minted its own scope layer, takes on the job of enforcing it. Its own publishing docs are explicit about the rule:
“The scope must match the selected publish owner. If your package is named @openclaw/dronzer, it can only be published as @openclaw. If you publish as @vintageayu, rename the package to @vintageayu/dronzer. This prevents a package from claiming an org namespace that the publisher does not control.”
The documentation describes exactly the protection npm provides. The ClawHub registry, however, did not apply that check to the org scopes in practice to all plugins or packages.
Of the 1,508 plugins in the catalog, 557 carry an ‘@owner/’ scope. But not all of those scopes are ownership-verified, and 23 of them sit under the ‘@openclaw/’ or ‘@clawhub/’ names while belonging to unrelated accounts.
Look at these two URLs, for example:
https://clawhub.ai/plugins/@openclaw/security-gate (archived version)
https://clawhub.ai/plugins/@clawhub/aisa-twitter-api (archived version)
Anyone reading those URLs would reasonably assume they come from the official, org-controlled namespaces.
Moreover, a developer running the following line of code, or seeing it in a script will not think twice either:openclaw plugins install clawhub:@clawhub/prediction-market
The naming makes it worse. Plugins called security-gate, prediction-market, or aisa-twitter-api under an official-looking scope can lead developers to install them believing they are ClawHub-built or ClawHub-endorsed.
In several cases the platform's own built-in security scan marks these packages as “pass” or clean.
The irony being: @openclaw/security-gate is a security-review plugin that isn't OpenClaw's, and it passed the registry’s own audit.
Trusted scopes and impersonation risk
Here is the part that matters most, and the part that is easy to get wrong.
At the time of our analysis, six of these plugins were flagged “suspicious” by ClawHub's own scanner.
We manually reviewed all six flagged plugins, and in fact every one of the 23 in the table, and found no outright malicious code in any of them. That is deliberately not the headline. The risk here is not a planted payload (in the versions we found; not accounting for future updates that could be malicious), but impersonation of high-privilege plugin types inside a trusted scope.
These are plugins that take autonomous payment actions, run host-level git and gh commands, export agent configuration, or egress to third-party APIs.
When code with that level of capability wears an @openclaw or @clawhub badge it did not earn, the scope stops being a trust signal and starts being a liability. A future bad actor does not need to smuggle in malware. They need only inherit the credibility the scope confers.
The full list of plugins we analyzed, all of which execute code inside the agent:
ClawHub Plugin | Owner handle | ClawHub Scan status | Executes code | Created |
@clawhub/prediction-market-arbitrage-zh | bibaofeng | clean | yes | 2026-04-04 |
@clawhub/prediction-market-arbitrage | bibaofeng | clean | yes | 2026-04-04 |
@clawhub/prediction-market-zh | bibaofeng | clean | yes | 2026-04-04 |
@clawhub/prediction-market | bibaofeng | clean | yes | 2026-04-04 |
@clawhub/aisa-twitter-api | bibaofeng | suspicious | yes | 2026-04-04 |
@openclaw/ralph-loop | pazyork | clean | yes | 2026-03-26 |
@openclaw/wework | tans | clean | yes | 2026-03-27 |
@openclaw/security-gate | dsda56180 | clean | yes | 2026-03-30 |
@openclaw/agent-exporter | jxh0229 | suspicious | yes | 2026-03-31 |
@openclaw/fiat-wallet | justiceessielp | suspicious | yes | 2026-04-02 |
@openclaw/zulip | niyazmft | clean | yes | 2026-04-03 |
@openclaw/open-prose | sheygoodbai | clean | yes | 2026-04-04 |
@openclaw/time-injection | willificent | clean | yes | 2026-04-06 |
@openclaw/knowledge-base-retrieval | kwokmoon | clean | yes | 2026-04-09 |
@openclaw/icpswap | onevroad-icp | suspicious | yes | 2026-04-13 |
@openclaw/xiaomifeng | renhongchao | clean | yes | 2026-04-14 |
@openclaw/openclaw-session-bloat-warning | teodorarg | clean | yes | 2026-04-18 |
@openclaw/openclaw-canon | teodorarg | clean | yes | 2026-04-18 |
@openclaw/openclaw-workflow-planner | teodorarg | clean | yes | 2026-04-18 |
@openclaw/openclaw-host-git-workflow | teodorarg | suspicious | yes | 2026-04-18 |
@openclaw/product-marketing-byteplus | sqsge | clean | yes | 2026-04-19 |
@openclaw/openclaw-url-tailwind-scaffold | teodorarg | clean | yes | 2026-04-21 |
@openclaw/codex-claw | 100yenadmin | suspicious | yes | 2026-05-03 |
The list comprises 23 code-executing plugins across 15 distinct accounts.
Some accounts hold clusters: all five @clawhub/ packages belong to one owner, and five of the @openclaw/ entries trace to another single account.
Most of these look like ordinary developers who published useful plugins and parked them under an official-looking scope, in several cases probably without realizing the scope was supposed to be reserved. That is the point, not a mitigation of it.
The gap was open enough that everyday contributors populated the official namespaces unchallenged. A motivated impersonator faces the same open door, with worse intent.
ClawHub adds a dispute process
On June 17th we notified the ClawHub maintainers via GitHub’s security advisory workflow, and further sent a courtesy email the following day.
Following our outreach, ClawHub's documentation gained a dedicated namespace-claims dispute process, letting rightful owners of an org, brand, scope, owner handle, or namespace request staff review:
“If you are the rightful owner of an org, brand, package scope, owner handle, or namespace that is already claimed or reserved on ClawHub, open an Org / Namespace Claim issue with public, non-sensitive proof. See Org and Namespace Claims for what to include and what to keep out of public issues.”
ClawHub's own FAQ, captured June 16, stated that “only publishers with access to the @openclaw owner can publish” under that scope, a guarantee that did not hold for the 23 plugins above. How long scope enforcement had applied to new publishes before that, the docs don't state.
By June 19th, the registry unlisted these misleading plugins from public view, following our report. Credit to Patrick Erichsen of ClawHub for the prompt action.
Do you know what your AI agents are running?
Skills, MCP servers, and now plugins: the AI agent supply chain is expanding faster than anyone's ability to watch it. ClawHub's plugin catalog alone sits at over 1,500 and is growing.
Plugins are more powerful than they look. A single one can attach hooks that forward your prompts or environment variables elsewhere, pull in additional skills, or alter agent settings, and it can do all of this while appearing benign, with no visibility on your side.
The scope problem we detail today makes that murkier still, because it hands "official" credibility to bootleg assets before anyone has run them.
This is the same pattern we have tracked across the ecosystem. We have exposed skills caught exfiltrating data and skills silently recruiting AI agents into a crypto swarm; following our reporting, those were removed. We have demonstrated and helped maintainers patch critical flaws in widely used MCP servers, as well as agentic VS Code extensions.
Our public supply chain index at manifest.manifold.security catalogs MCP servers, skills, and related AI assets so this kind of provenance gap is visible rather than buried. We're expanding it to cover plugins next.
This is what the attack surface of tomorrow looks like, and watching it at runtime is the only place these behaviors actually show up. Manifold's runtime detections, including via OpenTelemetry, close the gap between what a plugin claims and what it does once it is running inside your agent.
Scopes, badges, and audits tell you what a plugin claims to be. Manifold shows you what it actually does. From mapping your agent supply chain to monitoring runtime behaviour, we give you visibility across the full picture. Talk to us today.
Latest articles
