A supply-chain weakness in ClawHub’s plugin registry that allowed third-party packages to squat under organizational scopes and inherit first‑party credibility.
In a catalog review Manifold found 23 code‑executing plugins published under the @openclaw/ and @clawhub/ scopes by accounts that have no verified relationship to either organization.
Because ClawHub’s registry did not consistently enforce its documented rule tying a plugin’s scope to its verified owner, unaffiliated publishers were able to present plugins as if they were official OpenClaw integrations a trust failure with real operational risk.
Scope prefixes such as @owner/ are a provenance signal familiar from npm and other package registries: they indicate the account responsible for publishing and, by extension, the level of trust the artifact merits.
ClawHub adopted the same model for OpenClaw-compatible plugins and publishes genuine first‑party integrations under @openclaw (for example, @openclaw/whatsapp and @openclaw/codex).
The result: plugins named @openclaw/security-gate, @openclaw/fiat-wallet and @clawhub/aisa-twitter-api appeared to consumers as official, while their publishers were unrelated accounts.
Archive snapshots of these listings remain available and illustrate how a URL or install command such as openclaw plugins install clawhub:@clawhub/prediction-market can be misread as pulling an endorsed integration.
According to Manifold’s analysis, showed that 557 of the 1,508 plugins in ClawHub’s catalog carried an @owner/ scope, but not all scopes were ownership‑verified.
The immediate danger is not that the specific packages Manifold reviewed contained malware; after manual inspection none contained obviously malicious payloads.
ClawHub Scope Squatting
The greater concern is impersonation: these plugins execute code inside agents and perform sensitive actions autonomous payments, host‑level git and gh commands, exporting agent configuration, and egress to third‑party APIs.
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.
When such capabilities run under a scope that users assume is first‑party, the scope itself becomes a force multiplier for future abuse.
A malicious actor need not plant a payload in the original version; gaining the same misleading provenance is enough to trick operators into installing privileged plugins.
ClawHub’s own publishing documentation had long stated the protection that npm enforces the package scope must match the selected publish owner but the registry failed to apply that check comprehensively to org scopes.
Manifold reported the issue to ClawHub on June 17 via GitHub’s security advisory workflow and followed up by email.
ClawHub responded by adding a namespace‑claim dispute procedure and unlisting the most misleading plugins from public view by June 19, with public documentation updated to describe how rightful owners can request staff review.
This incident is a reminder that registries that mint their own scope layers take on responsibility for enforcing provenance.
Some registries sidestep the risk by deriving owner identity directly from GitHub repos, where ownership and publishing rights are already constrained.
Where a registry introduces scoped namespaces, rigorous verification, an automated enforcement check at publish time, and a fast dispute and takedown process are minimum requirements.
As AI agents and their supply chains proliferate, the plugin surface grows with them. Manifold’s ongoing work including a public supply‑chain index and runtime detection capabilities highlights the need for runtime monitoring and provenance visibility so that what a plugin claims aligns with what it actually does inside agents.
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.
