Skillv0.1.2

ClawScan security

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

Scanner verdict

SuspiciousMar 16, 2026, 3:04 PM

Verdict: suspicious
Confidence: high
Model: gpt-5-mini
Summary: The skill appears to implement DingTalk document operations as described, but the package metadata omits required credentials and the included helper script persistently stores sensitive tokens/credentials in a local config file — this mismatch and the way secrets are handled merit caution.
Guidance: This skill implements DingTalk document operations and includes a helper script that requires your DingTalk AppKey/AppSecret and user IDs. Before installing: 1) Expect to provide DINGTALK_APP_KEY, DINGTALK_APP_SECRET, DINGTALK_MY_USER_ID (and the script may write DINGTALK_MY_OPERATOR_ID) even though the registry metadata doesn't declare them. 2) The helper stores AppSecret and access tokens in plaintext at ~/.dingtalk-skills/config — consider whether you are comfortable with persistent local storage of these secrets. 3) Review scripts/dt_helper.sh yourself (it uses only api.dingtalk.com and oapi.dingtalk.com endpoints) and ensure you trust the skill source. 4) If you proceed, prefer using a dedicated account or sandbox environment, rotate AppSecret/token after testing, and consider restricting the app's scopes to the minimum required (read/write docs only). 5) If you need metadata accuracy/privacy guarantees, ask the publisher to update the registry requirements to list the required credentials and document where/how secrets are stored.

Review Dimensions

Purpose & Capability: noteThe SKILL.md and scripts implement DingTalk document and knowledge-base operations (token fetch, userId↔unionId conversion, CRUD on docs) which align with the skill's description. However the registry metadata declares no required env vars/credentials while the runtime instructions clearly require DINGTALK_APP_KEY, DINGTALK_APP_SECRET, DINGTALK_MY_USER_ID and DINGTALK_MY_OPERATOR_ID (stored in a local config). The omission in metadata is an incoherence.
Instruction Scope: noteThe SKILL.md confines actions to DingTalk API calls and to using the shipped helper script. It tells the agent to read/write a per-user config file (~/.dingtalk-skills/config), fetch tokens, convert IDs, and create temporary /tmp/<task>.sh scripts that it executes. Those steps are within the expected scope for a DingTalk doc skill, but the instructions give the agent the ability to persist credentials and run generated shell scripts — things the user should be aware of.
Install Mechanism: okThere is no install spec and no downloads; the skill is instruction-first and includes a helper shell script bundled in the skill. No external binaries or network downloads beyond calls to official DingTalk endpoints are introduced by an installer.
Credentials: concernAlthough the skill needs standard DingTalk credentials (AppKey/AppSecret and user IDs), these are not declared in the registry's required env vars. The helper script persists AppSecret and access tokens in plaintext under ~/.dingtalk-skills/config and uses them to call the API. Requesting and persistently storing these high-value secrets is proportionate to the functionality, but the metadata omission and plaintext persistent storage are concerning from a transparency and secrets-management perspective.
Persistence & Privilege: noteThe skill does not request platform-wide privileges or set always:true. It writes a per-user config file (~/.dingtalk-skills/config) and caches access tokens there; this is normal for credential caching but means credentials/tokens remain on disk until cleared. It also creates and executes /tmp/<task>.sh scripts for multi-line operations, which will execute shell commands the skill composes.