Pluginv2026.4.29-1

ClawScan security

WeCanBot Base · ClawHub's context-aware review of the artifact, metadata, and declared behavior.

Scanner verdict

SuspiciousApr 29, 2026, 11:39 AM

Verdict: suspicious
Confidence: high
Model: gpt-5-mini
Summary: The package largely matches its UI/orchestration purpose but the metadata under‑declares required credentials and install behavior; the package will read/write local OpenClaw state, run a local Node UI process, execute helper binaries, and can perform networked install handshakes — the combination and the recommended 'dangerously' install paths warrant caution.
Guidance: This package appears to implement the UI, workspace file store, and task router it claims, but there are a few mismatches and risky install recommendations you should weigh before installing: - Metadata omission: The registry lists no required env vars, but the code requires/reads CLAWSH server auth state (CLAWSH_SERVER_API_TOKEN) and other WECANBOT/OPENCLAW envs. Treat this as a transparency issue: expect the plugin to create/modify ~/.clawsh/cs-server.json and to persist tokens to disk. - Install risk: The README suggests running openclaw plugins install with --dangerously-force-unsafe-install and offers a curl | sh flow. Avoid piping unknown shells directly; prefer to inspect the installer and run in an isolated environment first. - Network & CLI activity: The bundled install helper will call your local OpenClaw server API (via fetch) and may invoke the 'openclaw' CLI to read gateway config. If you run this, ensure the openclaw binary and local gateway are trusted and accessible, and review the helper script source (install-server-auth.mjs) — it is included in the package. - Persistence: The plugin will spawn a Node UI process and register HTTP proxy routes. Consider running first in a sandbox or staging host, not on a production gateway, to verify behavior. - Audit recommendations: review the bundled install-server-auth.mjs and dist/index.js (they are included) for the precise network endpoints and filesystem paths used; back up existing ~/.clawsh state; verify that the server API endpoint used is your intended OpenClaw host; and if possible run the install on an ephemeral VM or container to observe runtime behavior before deploying to critical systems. If you want, I can extract and summarize the exact places the code reads/writes credentials, list all env vars the code references, or point to the specific files/lines where the install handshake and token writes occur.
Findings: [base64-block] unexpected: A base64-block pattern was detected in SKILL.md content by the pre-scan. The SKILL.md README itself doesn't clearly need embedded base64; this may come from templates or data in packaged files. It's unexpected for a short README and should be inspected to ensure no hidden payloads or large embedded data are present. [unicode-control-chars] unexpected: Unicode control characters were flagged in the SKILL.md. These can be used for prompt‑injection/obfuscation or accidental formatting. Given the plugin performs credential handshakes and writes tokens, any obfuscated instructions merit careful manual review.

Review Dimensions

Purpose & Capability: noteName/description (WeCanBot Base: UI, workspace & task tooling) align with the code: the plugin starts a local Node UI, registers proxy routes, and provides workspace_files and cs_task runtime tools. However, the registry metadata lists no required env/credentials while the code expects and enforces CLAWSH server auth state (CLAWSH_SERVER_API_TOKEN and related install session variables) and reads/writes ~/.clawsh state. The absence of those declarations in the registry metadata is an incoherence.
Instruction Scope: noteSKILL.md explicitly states it will start a Node UI process, read ~/.clawsh/cs-server.json, store workspace files, and expose a cs_task entrypoint; the code implements that. The install flow (and bundled helper) also performs network calls to the OpenClaw server API to obtain/install tokens and may invoke the local 'openclaw' binary. These are within the product description but are significant (credential storage, network token exchange, CLI invocation) and should be explicitly highlighted to users before install.
Install Mechanism: concernRegistry shows no install spec but the package includes compiled Node artifacts and an install helper. The published SKILL.md recommends 'openclaw plugins install ... --dangerously-force-unsafe-install' and allows a curl | sh flow — both are high-risk install patterns. The code does not download arbitrary archives from unknown URLs, but the use of an interactive/install helper that runs local commands and network requests plus the recommendation of a dangerous install flag elevates the install risk.
Credentials: concernThe registry lists no required env vars/credentials but the runtime code reads and enforces CLAWSH_SERVER_API_TOKEN and other WECANBOT_/CLAWSH_/OPENCLAW_ envs, reads/writes files under ~/.clawsh (server auth state and device identity), and may call the 'openclaw' CLI to query gateway config. Asking for and storing server API tokens and install session secrets is reasonable for a gateway plugin, but the metadata does not declare them; this mismatch is a red flag for transparency and proportionality.
Persistence & Privilege: noteThe plugin installs persistent server-side components: it will run a local Node UI process, register HTTP routes under the gateway, and create on-disk storage (sqlite DB and file store under a plugin-specific directory or under ~/.clawsh). It does not set always:true and does not claim to modify other skills' configs, so persistence is expected for this kind of plugin — but combined with undeclared credential handling and the dangerous install guidance, this persistent presence increases the blast radius and should be considered when granting installation privileges.