T09 · Insecure Skill Coding Practices
- Location
scripts/clawpay-cli.js:378- Finding
User-Controlled Skill ID Enables Archive Path Traversal
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This payment wallet skill also installs remote skill packages and writes local credentials, with install behavior that is too broad and under-scoped for automatic approval.
Review before installing. This skill is not just a payment QR helper: it can register a local client, store a signing key, download remote ZIP packages, and install files into the shared skills workspace. Only use it if you trust the dxmpay/clawpay service and package-signing pipeline, and prefer a version that validates skill IDs, installs only into an isolated expected directory, prevents overwriting existing skills without explicit consent, and stores credentials with owner-only permissions.
scripts/clawpay-cli.js:378User-Controlled Skill ID Enables Archive Path Traversal
scripts/clawpay-cli.js:393Signed Archives Can Overwrite Unrelated Skills in the Shared Skill Directory
scripts/clawpay-cli.js:280Authentication Private Key Is Stored Without Explicit Owner-Only Permissions
scripts/clawpay-cli.js:184Legacy TLS Server Compatibility Weakens Transport Security
The skill’s declared purpose is limited to payment QR handling, but the documented install flow expands its capabilities to key generation, client registration, remote package download, signature verification, unzip, and local skill installation. That is a major trust-boundary expansion: a payment helper effectively becomes a software installer, which increases supply-chain and unauthorized code installation risk if invoked unexpectedly or by broad trigger phrases.
The skill’s declared purpose is limited to payment QR handling, but the documented install flow expands its capabilities to key generation, client registration, remote package download, signature verification, unzip, and local skill installation. That is a major trust-boundary expansion: a payment helper effectively becomes a software installer, which increases supply-chain and unauthorized code installation risk if invoked unexpectedly or by broad trigger phrases.
The skill’s declared purpose is limited to payment QR handling, but the documented install flow expands its capabilities to key generation, client registration, remote package download, signature verification, unzip, and local skill installation. That is a major trust-boundary expansion: a payment helper effectively becomes a software installer, which increases supply-chain and unauthorized code installation risk if invoked unexpectedly or by broad trigger phrases.
Referenced artifact was not completely inspected
**脚本路径(Skill 下载安装)**: `scripts/clawpay-cli.js`
Referenced artifact was not completely inspected
**脚本路径(Skill 下载安装)**: `scripts/clawpay-cli.js`
Referenced artifact was not completely inspected
**脚本路径(Skill 下载安装)**: `scripts/clawpay-cli.js`
Referenced artifact was not completely inspected
**脚本路径(Skill 下载安装)**: `scripts/clawpay-cli.js`
The file implements client registration, key generation, package download, ZIP extraction, and installation into a shared skills workspace, which materially exceeds the described payment-link/QR-generation purpose. This creates a software installation/update channel inside a payment-related skill, increasing supply-chain and unauthorized code deployment risk even though the download is signature-checked.
The code downloads a remote ZIP and copies its extracted contents into the shared skills directory, which is a powerful code deployment capability. Although it includes hash/signature checks and path traversal defenses, compromise or misuse of the signing service, server, or authorized package pipeline would directly enable untrusted code to be installed into the local workspace.
Generic install triggers like “install skill” are too broad for a capability that downloads and installs remote skill packages. In context, this is especially risky because the skill is documented to perform configuration creation, remote download, verification, unzip, and local installation, so a casual phrase could trigger sensitive supply-chain actions.
Broad trigger phrases such as payment-related requests can overlap with normal conversation and unintentionally invoke a flow that generates payment artifacts or initiates related actions. In this skill’s context, accidental activation is more dangerous because the skill also ties into purchase and install-adjacent workflows, increasing the chance of confusing or coercive payment prompts.
The documentation states that the skill does not execute external commands, yet it explicitly instructs execution of Node scripts via shell. This contradiction can mislead reviewers and users about the skill’s execution model, causing them to underestimate command-execution, local file access, and script-trust risks.
Claiming the skill only handles audited structured JSON while the documented workflow includes multiple shell command executions is a dangerous transparency failure. In a skill ecosystem, this can lead downstream agents or operators to pass data into a component they believe is passive when it actually performs active command execution and installation-related actions.
The CLI generates an EC private key and stores it in clawpay.json on disk without any visible warning, passphrase protection, or permission hardening. If another local user, process, backup system, or malware can read that file, it can impersonate the client for signed requests and potentially download or query protected resources.
The skill download path writes a ZIP to the current directory, extracts it, and proceeds toward installation without an explicit pre-install warning or confirmation step. In context, this means a payment-wallet-related skill can cause local filesystem modifications and stage code for installation with limited user awareness.
The file’s natural-language comments and all user-facing messages are written in Chinese, including usage text and success/error outputs. There is no indication that the skill is intentionally region-specific or that users can opt into a preferred language, which creates a locale-policy issue under the language-choice rule.
The file-level security comment says the short-link feature is disabled by default and requires an explicit flag, but the standalone CLI path initializes enableShortUrl to true and only disables it when --long-url is passed. The usage text also says --short-url is required, even though that flag is never parsed and short-linking is effectively on by default.
The user-facing trigger and behavior description is written as Chinese-only interaction guidance, while also including one English trigger phrase, but there is no statement that the skill supports multiple languages or follows the user's preferred locale. This can create a locale policy issue if the skill defaults to Chinese responses without user opt-in.
This CLI contains natural-language comments and user-visible output such as error and status messages in Chinese only, with no indication of language selection or opt-in. That can violate a language/locale policy when a skill imposes a specific language on all users without offering a choice.
The JSDoc declares that success returns data shaped as { qr: string, fp: string }, but the implementation actually returns { qr, fp, url }. This is an active mismatch between documented intent and actual behavior.