• 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.

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:

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

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.