The Provenance Gap: Analyzing Scope Squatting Vulnerabilities in ClawHub’s Plugin Registry

A critical supply-chain weakness has been identified within the ClawHub plugin registry, specifically concerning a failure in namespace enforcement. This vulnerability allowed third-party actors to “squat” under organizational scopes, effectively inheriting the first-party credibility of established entities like OpenClaw.

During a comprehensive catalog audit, Manifold Security discovered 23 code-executing plugins published under the @openclaw/ and @clawhub/ scopes. These packages were published by accounts with no verified relationship to the respective organizations, representing a significant breakdown in trust architecture.

The core of the issue lies in a disconnect between policy and enforcement. While ClawHub’s documentation explicitly mandates that a plugin’s scope must align with its verified owner, the registry failed to programmatically enforce this rule. This oversight allowed unaffiliated publishers to present their artifacts as official OpenClaw integrations—a failure that introduces substantial operational risk to the ecosystem.

In modern software distribution, scope prefixes (such as @owner/) serve as vital provenance signals. Much like the scoping model used by npm, these prefixes act as a shorthand for trust, indicating the specific entity responsible for the artifact’s lifecycle and security posture.

ClawHub adopted this industry-standard model, utilizing @openclaw for genuine first-party integrations, such as @openclaw/whatsapp and @openclaw/codex. However, the lack of registry-level validation enabled the emergence of lookalike packages, including @openclaw/security-gate, @openclaw/fiat-wallet, and @clawhub/aisa-twitter-api. To a standard user, these appeared to be endorsed integrations, despite being hosted by unrelated third parties.

Archived snapshots of these listings demonstrate how easily a user could be deceived. For instance, an installation command like openclaw plugins install clawhub:@clawhub/prediction-market carries a veneer of legitimacy that masks the lack of underlying verification.

According to Manifold’s technical analysis, while 557 of the 1,508 plugins in the ClawHub catalog utilized an @owner/ scope, a significant portion of these scopes lacked actual ownership verification.

The Risk of Impersonation and Privileged Execution

It is important to note that Manifold’s manual inspection did not find immediate evidence of malicious payloads in the specific packages reviewed. However, the absence of malware in this instance does not mitigate the structural danger: impersonation is a force multiplier for future attacks.

Because these plugins are designed to execute code within autonomous agents, they possess highly sensitive capabilities. This includes performing autonomous payments, executing host-level Git and GitHub commands, exporting agent configurations, and establishing egress to third-party APIs. If an actor successfully hijacks the “trust” associated with a scope, they can bypass the psychological barriers that usually prevent users from installing unverified code.

Consider the security model of the @microsoft/microsoft-graph-client package on npm. Because npm enforces strict organizational scoping, a developer can operate under the reasonable assumption that any package under @microsoft is an official product. The scope itself acts as a security primitive. In ClawHub’s case, the scope became a deceptive tool rather than a protective layer.

A sophisticated attacker does not need to compromise a legitimate package. They simply need to exploit the registry’s failure to verify provenance to trick operators into granting privileged access to an “official-looking” but malicious integration.

Remediation and Moving Forward

Upon Manifold reporting the vulnerability via GitHub’s security advisory workflow on June 17, ClawHub moved to remediate the issue. By June 19, the organization had implemented a namespace-claim dispute procedure, unlisted the most misleading plugins, and updated their documentation to provide a pathway for rightful owners to request manual reviews.

This incident highlights a fundamental principle for registry maintainers: whenever a platform introduces its own scoping or namespacing layers, it assumes the responsibility of enforcing provenance.

To mitigate these risks, registries should consider several architectural approaches:

• Identity Derivation: Deriving owner identity directly from established providers like GitHub, where ownership and publishing rights are already strictly managed.
• Automated Enforcement: Implementing rigorous, automated checks at the “publish” stage to ensure the requested scope matches the authenticated owner.
• Rapid Response: Maintaining a fast-track dispute and takedown process for contested namespaces.

As the AI agent landscape expands, the plugin attack surface will grow exponentially. Manifold’s ongoing research—including the development of a public supply-chain index and runtime detection capabilities—underscores a vital truth: as the complexity of autonomous software increases, we must move toward a model where runtime monitoring ensures that a plugin’s behavior strictly aligns with its claimed provenance.