PERMISSION/PROTOCOL
Back to incident tracker

2026-06-22

HighMedia report

23 ClawHub Plugins Published Under Official @openclaw/ and @clawhub/ Scopes by Unauthorized Accounts, Exposing Claude Code and Cursor to Supply Chain Risk

Manifold Security found 23 ClawHub plugins published under @openclaw/ and @clawhub/ scopes by unauthorized accounts, exposing Claude Code, Cursor, and Codex to silent supply chain compromise.

ClawHubTool execution / MCPRegistry scope squatting / supply chain impersonationClawHub plugin registry — primary source for Claude Code, Cursor, and Codex plugin installs (1,500+ plugins)

What happened

Third-party accounts published 23 code-executing plugins under @openclaw/ and @clawhub/ organizational scopes on ClawHub without authorization, making them appear to be official OpenClaw tools to any developer browsing or scripting plugin installs.

Why it matters

23 plugins with user-level authority inside agent environments appeared as trusted official tools on the registry used by Claude Code, Cursor, and Codex. Developers installing them had no visible signal the plugins were not official. Several performed high-privilege actions including autonomous payment processing, host-level git commands, agent configuration export, and external API connections.

Missing authorization check

Scope ownership verification enforced at point of publication — not post-publication auditing — to prevent unauthorized accounts from publishing under reserved organizational namespaces.

Would PP block it?

PP enforcement sits at the action layer, not the plugin installation or scope-validation layer. A scope-squatted plugin that triggers a payment or git push inside the agent environment would need a PP-signed receipt for those specific actions. The plugin can look official in the registry but cannot produce a valid PP authority receipt without going through the external enforcement gate. What PP does not close: it cannot prevent installation of a misleading plugin or stop low-privilege actions the plugin executes before reaching PP’s enforcement boundary.

Incident analysis

Timeline and technical read

Timeline

  1. 2026-06-17

    Manifold Security reports 23 scope-squatting plugins to ClawHub via GitHub’s security advisory workflow.

  2. 2026-06-18

    Manifold sends a courtesy email to ClawHub to confirm the disclosure was received.

  3. 2026-06-19

    ClawHub unlists all 23 misleading plugins and adds a formal dispute process for reporting unauthorized namespace usage.

  4. 2026-06-22

    Manifold Security publishes findings; CybersecurityNews and Help Net Security cover the disclosure.

Technical breakdown

  • ClawHub’s scoping system mirrors npm’s @owner/ convention, where the prefix signals the publishing organization. Unlike npm, ClawHub did not consistently enforce that only verified org members could publish under reserved scopes.
  • Of 1,508 plugins in the catalog, 557 carry an @owner/ prefix, but not all have verified ownership. The 23 rogue plugins belong to 15 distinct external accounts.
  • Plugin names like @openclaw/security-gate, @openclaw/fiat-wallet, and @clawhub/aisa-twitter-api impersonated platform-level tools. @openclaw/security-gate — a security-review plugin — even passed ClawHub’s own scanner despite not belonging to OpenClaw.
  • All 23 plugins execute code inside agent environments. Several perform high-privilege actions including autonomous payment processing, host-level git commands, agent config export, and external API connections.
  • Manifold found no confirmed malicious code in reviewed versions, but the supply chain risk is latent: a single future update to any of these plugins could introduce harmful behavior with no visible warning to developers who trust the @openclaw/ scope.

Authorization boundary

Where the authorization boundary should have been

This incident is categorized as Tool execution / MCP. The relevant Permission Protocol gate is Runtime Gate. The read is conditional: the block only applies where the real action boundary is routed through a gate.

If enforced at
Payment gate, data mutation gate, git execution gate, external API call gate
Still needs
Plugin installation path, scope validation at the registry level, and low-privilege actions below PP’s enforcement boundary
Receipt required for
Autonomous payment processing, git operations, agent configuration exports, and external API connections made by the plugin inside the agent

PP’s authorization chain is external to the plugin registry. Even if a scope-squatted plugin executes inside an agent, high-impact actions (payments, git mutations, credential exports) require PP-signed receipts issued through an independent channel the plugin cannot forge.

Start small

Put the relevant gate at this action boundary.

This incident maps to Runtime Gate. Start with the boundary that controls the actual action, then require a signed receipt before execution.

Replay this incident with a signer in the loop