T09 · Insecure Skill Coding Practices
- Location
scripts/payment.mjs:140- Finding
Token amounts are signed using chain-native decimals instead of token-specific decimals
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill is mostly coherent for creating PayTheFlyPro crypto links, but it can sign withdrawal or payment authorizations with incorrect token amounts for non-native tokens.
Review carefully before installing or using for real funds. Use a dedicated signer key as documented, pin and review npm dependencies, and avoid custom token payment or withdrawal links until token decimals are correctly resolved or explicitly verified before signing.
scripts/payment.mjs:140Token amounts are signed using chain-native decimals instead of token-specific decimals
SKILL.md:25Unpinned runtime dependencies create a non-reproducible software supply chain
The skill requires sensitive environment variables, including a private signing key, but does not declare an explicit tool scope or permissions model. That omission can cause users or hosting agents to run the skill without clear least-privilege boundaries, increasing the risk of unintended secret exposure or misuse of code execution capabilities.
The script reads PTF_SIGNER_KEY from the environment and later uses it to create a wallet for signing, which is a sensitive credential-handling operation. While the usage text lists the variable as required, there is no warning about the sensitivity of the private key, safe handling expectations, or the security implications of loading it into the process.
The payment-link options specify --lang <code> with only en, zh, ko, ja, which constitutes a language/locale restriction in the natural-language documentation. The file does not explain why only these locales are allowed or frame this as a user-selectable limitation for a region-specific tool.
The withdrawal options expose --lang <code>: UI language but do not clarify supported locales, user choice, or any reason for restricting interface language. Under the policy, forced or unclear language constraints should be documented or made explicitly opt-in.
The help text advertises --lang <code> with a hard-coded set of supported languages (en, zh, ko, ja), which introduces a locale constraint in the skill interface. The file does not explain default behavior or whether language choice is always user-directed, creating a mild risk of language/locale policy ambiguity.
No suspicious patterns detected.