FHN 
A recently disclosed supply chain weakness in ClawHub’s plugin registry allowed third-party developers to publish plugins under organizational namespaces they did not own. As a result, unofficial plugins appeared to be legitimate OpenClaw or ClawHub integrations, creating a significant trust and security concern for users.
What Happened?
Security researchers at Manifold discovered that ClawHub’s registry was not consistently enforcing ownership verification for plugin namespaces.
During their review, they identified 23 code-executing plugins published under the @openclaw and @clawhub namespaces by accounts that had no verified connection to either organization.
Because these namespaces are commonly associated with official software publishers, many users could easily assume the plugins were legitimate first-party integrations.
Why Namespace Verification Matters
Modern package registries use namespace prefixes such as @owner/ to indicate who published a package. This system helps users determine whether a package originates from a trusted source.
For example, developers generally trust packages published under Microsoft’s verified namespace because registry controls prevent unauthorized users from publishing under that name.
ClawHub adopted a similar namespace model for OpenClaw-compatible plugins. Official integrations such as @openclaw/whatsapp and @openclaw/codex are published under the OpenClaw namespace, reinforcing user trust.
The Scope Squatting Problem
The issue arose because unaffiliated publishers were able to create plugins using trusted namespaces without proper ownership verification.
Examples included plugins such as:
- @openclaw/security-gate
- @openclaw/fiat-wallet
- @clawhub/aisa-twitter-api
Although these plugins were not created by OpenClaw or ClawHub, their names made them appear official.
Installation commands and registry listings further increased the risk of confusion, potentially leading users to install plugins they believed were endorsed by the organizations.
Why This Is a Security Concern
Manifold’s investigation found that many plugins within the registry used scoped namespaces, but not all of them were ownership verified.
Importantly, researchers did not find obvious malware in the reviewed plugins. However, the primary concern is not the current content of these packages—it is the trust they inherit from misleading namespaces.
Many ClawHub plugins can:
- Execute code inside AI agents
- Access external APIs
- Export agent configurations
- Run Git and GitHub commands
- Perform automated actions on behalf of users
When users mistakenly trust a plugin because of its namespace, attackers gain a powerful opportunity for future abuse.
How ClawHub Responded
Manifold reported the issue to ClawHub through GitHub’s security advisory process on June 17 and later followed up via email.
Within days, ClawHub introduced several remediation measures, including:
- A namespace ownership dispute process
- Removal of misleading plugins from public listings
- Updated documentation explaining how legitimate owners can claim namespaces
- Additional review procedures for namespace ownership requests
These actions helped reduce the immediate risk and improve transparency within the registry.
Lessons for Plugin Registries
This incident highlights the importance of strong provenance controls in software ecosystems.
Any registry that introduces organizational namespaces must ensure:
- Namespace ownership verification
- Automated enforcement during publishing
- Continuous monitoring for impersonation attempts
- Fast dispute resolution and takedown processes
Without these safeguards, trusted namespaces can become an avenue for supply chain attacks and software impersonation.
Looking Ahead
As AI agents and plugin ecosystems continue to grow, so does the importance of software provenance and supply chain security.
Organizations must not only verify who publishes a plugin but also maintain visibility into what those plugins are capable of doing after installation.
The ClawHub scope squatting incident serves as a reminder that trust signals are only effective when they are backed by strong verification and enforcement mechanisms.
About the Author
