Back to skill
Skillv1.0.13
ClawScan security
jd-clawtip-payment-skill · ClawHub's context-aware review of the artifact, metadata, and declared behavior.
Scanner verdict
SuspiciousMar 30, 2026, 6:23 AM
- Verdict
- suspicious
- Confidence
- medium
- Model
- gpt-5-mini
- Summary
- The skill mostly does what its name describes (processes jd-clawtip payments), but there are implementation and framing inconsistencies (missing runtime binary requirements, plaintext/base64 token handling, verbose token output, and an unknown source) that warrant caution before installing.
- Guidance
- This skill appears to implement a jd-clawtip payment protocol, but review and consider the following before installing or enabling it: 1) Runtime requirements: the scripts call node (test2.js) via subprocess but the skill metadata does not declare node as a required binary — ensure your environment provides a trusted Node runtime. 2) Token handling: the skill stores userToken in configs/config.bin encoded only with base64 and prints tokens to stdout; this can leak secrets to logs or to calling code. If you will use it, ensure the config folder is appropriately protected and consider modifying the code to encrypt the file with a real key and stop printing raw tokens. 3) Network endpoints: the skill talks to ms.jr.jd.com and other JD endpoints — verify these are the expected/authorized endpoints for your deployment. 4) Source trust: the skill has no homepage and an unknown owner; verify provenance before granting credential read/write permissions. 5) Least privilege: restrict network and credential permissions to only what is necessary and confirm the calling skill is authorized to receive any tokens/credentials this skill emits. If you need higher assurance, request a signed/hosted release or run the code in a sandboxed environment and inspect runtime network calls and outputs.
Review Dimensions
- Purpose & Capability
- noteThe code implements payment request construction, token creation/registration checks, and network calls to JD endpoints which align with the declared purpose. However the package invokes Node (test2.js) for encryption but the skill metadata/requirements list no required binaries — a practical mismatch. The SKILL.md version (1.0.1) differs from registry version (1.0.13), which could indicate sloppy packaging or untracked changes.
- Instruction Scope
- concernThe SKILL.md and scripts read and write a local config file configs/config.bin to store userToken (base64-encoded), call external JD endpoints, and run a bundled Node.js crypto script. The scripts also print sensitive tokens and API responses to stdout. Printing tokens to stdout and storing them only base64-encoded increases the risk of accidental token leakage (to logs, callers, or other skills). The SKILL.md's runtime instructions expect the agent to execute python and implicitly node; the skill instructs preserving outputs in memory and handing encrypted blobs back to calling skills — reasonable for the protocol but sensitive in practice.
- Install Mechanism
- noteThis is an instruction-only skill packaged with code files (Python + bundled JS cryptico library). There is no install spec (nothing written to disk by a platform installer), but the skill will create and modify files under its own configs/ directory at runtime. The bundled cryptico JS is sizable but from the included file; there are no external arbitrary download URLs. The absence of an explicit runtime requirement listing (node) is a packaging oversight.
- Credentials
- concernThe skill declares and uses credential.read and credential.write permissions and network.outbound, which are consistent with storing a userToken and calling JD endpoints. However it requests no environment variables or external credentials from the platform; instead it persists sensitive tokens locally (base64 encoded) and prints them to stdout. That local persistence and stdout exposure are disproportionate risk for a third-party skill unless you trust the caller and the endpoint (ms.jr.jd.com).
- Persistence & Privilege
- okalways is false and the skill only writes files under its own configs/ folder. It does not request to modify other skills or system-wide config. The persistence is limited to storing a local token cache, which is a reasonable pattern — but again the storage method is weak (base64) and tokens are printed to stdout.
