T09 · Insecure Skill Coding Practices
- Location
assets/template/src/server.cjs:42- Finding
Customer Wallet Private Keys Stored in Plaintext
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill is a payment bot scaffold, but its template contradicts its own safety rules by storing wallet private keys locally and signing blockchain transactions from the server.
Treat this as Review before installation. Do not use it with real funds or production Telegram users unless it is redesigned to avoid server-side private key custody and server-side signing, removes the unused treasury private key, enforces secure service-to-service transport, fixes vulnerable dependencies, and clearly documents the payment trust model.
assets/template/src/server.cjs:42Customer Wallet Private Keys Stored in Plaintext
assets/template/src/server.cjs:129Server Signs Transactions on Behalf of Users Contrary to Declared Safety Rules
assets/template/src/server.cjs:20Unused Treasury Private Key Is Required and Loaded into the Web Process
assets/template/src/telegram-bot.cjs:5Billing Bearer Credential Can Be Sent to an Arbitrary Plaintext HTTP Endpoint
references/PUMP_TOKENIZED_AGENTS.md:11Mutable External Skill Reference Introduces Instruction Supply-Chain Risk
This mismatch shows the skill claims to implement payment and Telegram/server integration logic, but may actually only perform template stamping without the promised verification and payment functionality. In a payments context, that can lead downstream users to deploy incomplete or insecure systems under the false assumption that invoice/payment validation is present, causing broken payment controls or unsafe custom additions.
This mismatch shows the skill claims to implement payment and Telegram/server integration logic, but may actually only perform template stamping without the promised verification and payment functionality. In a payments context, that can lead downstream users to deploy incomplete or insecure systems under the false assumption that invoice/payment validation is present, causing broken payment controls or unsafe custom additions.
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
cd demo-billing
cp .env.example .env
# edit .env and set:
# - TREASURY_SECRET_KEY_BASE58
# - API_TOKEN
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
cd demo-billing
cp .env.example .env
# edit .env and set:
# - TREASURY_SECRET_KEY_BASE58
# - API_TOKEN
npm start
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
```bash
cd demo-billing
cp .env.example .env
# edit .env and set:
# - TREASURY_SECRET_KEY_BASE58
# - API_TOKEN
npm start
The lockfile pins bigint-buffer 1.1.5, which is reported vulnerable to a buffer overflow in toBigIntLE(). Even though this package is transitive, shipping a known vulnerable native/binary-adjacent parsing dependency in a payment-oriented Solana stack creates real memory-safety risk if attacker-controlled data can reach the affected code path.
fast-uri 3.1.0 is a known vulnerable dependency and is used by Fastify's schema/URL handling stack. The cited host confusion and SSRF-class issues are especially relevant in a web server template, because malformed URLs, IDNs, or authority parsing discrepancies can undermine origin validation, allow outbound request abuse, or bypass security checks that rely on canonical host parsing.
fastify 5.8.2 is directly included by the template and the advisories affect core request parsing, schema validation, and forwarded host/protocol handling. In a Telegram+web payment bot scaffold, validation bypasses or spoofed host/protocol values can lead to authentication mistakes, webhook trust errors, poisoned callback URLs, or acceptance of malformed payment-related requests.
find-my-way 9.5.0 is Fastify's router and is reported vulnerable to HTTP/2-triggered DoS. Because this skill generates an internet-facing web server, an attacker could exploit expensive routing behavior to degrade availability, which is meaningful for payment verification and bot endpoints even if it is not a direct compromise of confidentiality or integrity.
ws 8.19.0 is reported vulnerable to memory disclosure and memory exhaustion DoS. In a stack that includes Solana RPC/websocket functionality, a vulnerable websocket client/server library can expose sensitive process memory or allow remote resource exhaustion if attacker-controlled websocket traffic is accepted or proxied.
toml 3.0.0 is flagged for uncontrolled recursion and prototype pollution. Although likely transitive via Anchor tooling, prototype pollution in Node.js dependency chains can become serious if untrusted TOML is ever parsed, and recursion flaws can enable denial of service; however in this runtime template the package is less obviously exposed than the web server components.
ws 7.5.10 is vulnerable to memory exhaustion DoS from tiny fragments/data chunks. Because this older websocket version is also present in the dependency tree, the application may remain exposed even if newer branches are patched elsewhere, and availability attacks are particularly damaging for bot polling, RPC connectivity, and payment-verification services.
The manifest includes fastify 5.8.2, which is explicitly identified as affected by multiple advisories, including schema validation bypasses and spoofable request protocol/host handling. In this skill's context, that is more dangerous because it scaffolds an internet-facing Express-style/Fastify web server for payment and invoice verification flows, where request spoofing or validation bypass can undermine trust boundaries, routing, security checks, or payment-related business logic.
The code explicitly stores generated deposit private keys in plaintext Base58 form inside SQLite. This creates a single highly sensitive theft target; any local file disclosure, backup leak, SQL access, or host compromise exposes private keys that allow immediate draining of user funds.
Persisting per-user private keys in a local SQLite database without any disclosure or protection details is a serious secret-management flaw. Anyone who gains filesystem, backup, log, or database access can recover those keys and drain user wallets, and users are not informed that the service is acting as a custodian. The skill context makes this more dangerous because it is presented as a ready-made scaffold likely to be copied into real services.
This function signs and broadcasts a Solana transaction using a server-controlled deposit wallet, which is an irreversible external operation. The code has only an internal implementation comment and lacks any user-facing warning, confirmation step, or documented disclosure that funds may be moved on-chain automatically.
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
( cd "$TEMPLATE_DIR" && tar -cf - . ) | ( cd "$OUT_DIR" && tar -xf - )
# Remove common local state if it slipped in
rm -f "$OUT_DIR"/*.log "$OUT_DIR"/*.pid "$OUT_DIR"/demo.db "$OUT_DIR"/.env "$OUT_DIR"/.env.local 2>/dev/null || true
echo "Stamped template to: $OUT_DIR"
echo "Next: cd '$OUT_DIR' && npm install"
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
( cd "$TEMPLATE_DIR" && tar -cf - . ) | ( cd "$OUT_DIR" && tar -xf - )
# Remove common local state if it slipped in
rm -f "$OUT_DIR"/*.log "$OUT_DIR"/*.pid "$OUT_DIR"/demo.db "$OUT_DIR"/.env "$OUT_DIR"/.env.local 2>/dev/null || true
echo "Stamped template to: $OUT_DIR"
echo "Next: cd '$OUT_DIR' && npm install"
Without declared permissions the skill's intent is opaque and cannot be validated.
The README instructs operators to place a treasury private key and API token into a local .env file without any warning about secret handling, storage hygiene, rotation, or preventing accidental disclosure. In a payment-handling Solana/Telegram service, this increases the chance that high-value credentials are mishandled, committed to source control, or exposed in logs or screenshots, leading to wallet compromise or unauthorized API use.
This code loads a treasury secret key from an environment variable and configures a database path, then later stores per-user deposit private keys in the database. There is no confirmation prompt, visible warning, or explanatory comment disclosing that sensitive credentials and user wallet secrets are being handled and persisted locally.
The server generates and persistently stores per-user Solana private keys in SQLite, making the application a custodial wallet system rather than a simple payment scaffold. If the database, backups, logs, or host are compromised, attackers can extract user wallet secrets and steal all funds from those deposit wallets.
The deposit check accepts any existing wallet balance as satisfying a new funding request, without proving that a fresh deposit corresponding to the current request occurred. Because deposit wallets are reused per user, previously leftover funds can be counted again for later crediting flows, enabling replay-style over-crediting or mismatched accounting.
These lines serialize and broadcast a signed transaction, transmitting wallet activity to the Solana RPC endpoint. The code does not include a confirmation prompt, visible log/print, or explanatory warning near the operation, even though it initiates an external network action affecting funds.
This handler debits credits from a user's stored balance, which is a destructive state change. There is no visible confirmation, warning, or explanatory disclosure in the code around this irreversible operation.
Detected: suspicious.env_credential_access