T09 · Insecure Skill Coding Practices
- Location
index.js:12- Finding
Hardcoded SkillPay API Credential Exposed in Source and Configuration
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill has a coherent paid crypto-signal purpose, but its payment and API implementation exposes a hardcoded financial API key and trusts caller-supplied billing identity.
Review before installing. The publisher should remove and rotate the embedded SkillPay key, require injected secrets, bind billing to authenticated platform identity, validate requests before any charge, pass the advertised price explicitly, add idempotency/duplicate-charge protections, disclose what user data is sent to SkillPay, and pin reviewed dependencies.
index.js:12Hardcoded SkillPay API Credential Exposed in Source and Configuration
index.js:80Caller-Controlled User Identifier Is Trusted for Billing and Paid API Access
index.js:25Broken Billing Workflow Uses a Zero Charge and Bills Before Input Validation
The file hardcodes a live-looking API key fallback and exposes billing and core analysis logic despite comments claiming these are private and not public. If this code is distributed with the skill, attackers can recover the secret, abuse the billing API, and replicate or tamper with the supposedly protected backend behavior.
The manifest states that the SkillPay API key should be supplied via environment variables, yet a live-looking secret is embedded directly in the configuration. Hardcoded secrets are easily leaked through source distribution, logs, or package reuse, allowing unauthorized parties to use the payment integration, impersonate the skill, or incur fraudulent charges.
A hardcoded payment API key is present in the skill configuration, which exposes a credential tied to financial operations. Because this is a crypto/payment-oriented skill, misuse of the leaked key could directly affect billing flows, generate fraudulent payment requests, or enable unauthorized API consumption, making the context more dangerous than an ordinary non-financial integration.
This README presents the skill name, usage instructions, pricing, outputs, and warnings entirely in Chinese. That effectively forces a specific language for all users without offering a language/locale choice or documenting that the skill is intended only for a Chinese-language audience.
This code sends the user's identifier and skill identifier to an external billing endpoint via HTTP, which is a network transmission of user/system data. Although comments describe billing internally, there is no visible confirmation prompt, log, or user-facing disclosure warning that this transmission occurs.
The manifest presents the skill name, description, category, tags, examples, and disclaimer entirely in Chinese, with no indication that users can choose another language or locale. This is a natural-language policy concern because the skill appears to enforce a single language experience without explicit user opt-in or documented regional limitation.
The code sends user identifiers and requested token symbols to an external paid API, and separately sends billing data to a third-party billing service. In this context, the risk is elevated because a hardcoded fallback API key is present, making unauthorized use of those external endpoints more feasible if the source is exposed, and because data is transmitted off-platform without any visible minimization or consent controls.
const SKILL_ID = process.env.SKILL_ID || 'crypto-short-signal';
// 付费层 API 地址 (可以部署在 SkillPay Cloud 或你的服务器)
const PAID_API_URL = process.env.PAID_API_URL || 'https://api.skillpay.me/skills/crypto-short-signal/analyze';
const headers = {
'X-API-Key': API_KEY,
The skill charges the user before validating input and without any explicit confirmation or visible pre-charge warning in this code path. In an agent setting, this can lead to unintended charges, especially when malformed or empty input is submitted, and can be abused through repeated invocations that debit balances without delivering useful service.
The example output sets risk_level to the Chinese value 高 inside an otherwise English-language skill description and response schema. This suggests the skill may force a specific language or locale in outputs without user opt-in or documented language selection.
Natural-language strings and comments indicate the skill is oriented to Chinese only, and all user-facing messages returned by the API are in Chinese. There is no indication that the user can choose language or that the locale restriction is explicitly documented as an intentional regional constraint.
User-facing messages and descriptions in this file are written in Chinese, and there is no indication that users can choose another language or that the skill is intentionally limited to Chinese-speaking users. That can violate language/locale policy when a specific language is imposed without opt-in or justification.
The module header at L4-L6 says the public layer 'only contains billing interfaces and basic validation' and that core logic is elsewhere. However, the code also returns product metadata and strong marketing claims such as '提前 7 天知道哪些币要暴跌 30%+' in normal execution, which goes beyond the stated limited role of just billing/validation.
The package description is written entirely in Chinese, which indicates a fixed language choice in the skill's user-facing metadata. There is no accompanying opt-in, alternative locale, or justification that this skill is intended only for a Chinese-speaking or region-specific audience.
The dependency uses a caret range (^1.13.6), which allows future minor/patch updates to be installed without review. In a security-sensitive skill, this weakens supply-chain integrity and can unexpectedly introduce vulnerable or malicious dependency versions during install or deployment.
"author": "Denny Huang",
"license": "MIT",
"dependencies": {
"axios": "^1.13.6"
},
"engines": {
"node": ">=18.0.0"
The manifest declares axios without an exact pinned version, while known advisories exist for some axios releases. Because the actual installed version is not fixed or evidenced by a lockfile here, consumers may resolve to an affected release, creating risk such as SSRF, credential leakage, or request/response manipulation depending on how the library is used elsewhere in the skill.