Skillv1.0.1

ClawScan security

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

Scanner verdict

SuspiciousMar 20, 2026, 2:45 AM

Verdict: suspicious
Confidence: high
Model: gpt-5-mini
Summary: The skill mostly matches its stated purpose (website monitoring using Puppeteer) but contains unsafe behavior (shelling out with unsanitized scraped text) and some mismatches between documentation and implementation — review/patch before installing.
Guidance: What to consider before installing: - Major risk: the skill shells out to openclaw with the notification message embedded in a single command string. Because the message is built from scraped titles (external websites), an attacker-controlled site could craft content that executes arbitrary shell commands on your host. Don’t install or run this skill on systems you cannot afford to compromise. - If you still want the functionality, ask the author to patch before use: replace execSync(string) with a safe alternative (execFile/spawn with argument array or use the OpenClaw messaging API/library), or thoroughly sanitize/encode the message to prevent shell expansion (escape $, `, \\, newlines, etc.). - Ask for or apply these fixes: implement the other promised notify channels (webhook/email/wechat) properly; make state/log paths configurable (use ~/.openclaw/workspace by default) and document required host CLI credentials; avoid saving state inside the installed package directory. - Additional operational notes: Puppeteer will download/consume a Chromium binary and increase disk/network usage. Only run on trusted hosts and consider running inside an isolated container or VM until the command-injection issue is resolved. Confidence notes: High — the execSync call with interpolated, unsanitized message text is visible in code and is a straightforward command-injection vector. If you can confirm that the host 'openclaw message' CLI itself safely treats its arguments (no shell expansion) and that execSync is invoked in non-shell mode (not the case here), or that all monitored sites are fully trusted and cannot be tampered with, that would reduce the risk.

Review Dimensions

Purpose & Capability: noteThe code implements a Puppeteer-based crawler/monitor and supports cron/dedup/keyword filtering as described. However the SKILL.md claims multiple notification channels (DingTalk/WeChat/Email/Webhook) while the implementation only actually invokes a DingTalk path (via the openclaw CLI) and otherwise just prints messages. Also docs reference state/log paths under ~/.openclaw/workspace but the code saves state to the skill's ../state directory — an inconsistency.
Instruction Scope: concernNotifier.send uses child_process.execSync to run a shell command embedding the generated message text directly: execSync(`openclaw message send --target "${config.target}" --message "${message.replace(/"/g, '\\"')}"`). The message content is derived from scraped page titles/metadata controlled by external websites — this allows shell command injection (e.g. $(...), backticks, or other shell expansions) and could result in arbitrary command execution on the host. The SKILL.md does not warn about this risk and claims other notification channels that are not implemented in code.
Install Mechanism: noteNo explicit install spec is provided in the registry metadata (instruction-only), but the package.json lists Puppeteer and other npm deps; installing will likely pull large browser artifacts (Chromium) via Puppeteer. That is expected for a headless browser crawler but increases installation footprint.
Credentials: noteThe skill declares no required environment variables or credentials, which matches the code. However the use of the 'openclaw message send' CLI implies the runtime agent/host CLI will be invoked and may rely on platform credentials not declared by the skill. The skill does not request or document those credentials or permissions.
Persistence & Privilege: okalways is false and the skill does not request elevated platform privileges. It writes state to a local 'state' directory inside the skill package (../state) rather than the documented workspace path — this is an implementation quirk but not an elevated privilege request.