T09 · Insecure Skill Coding Practices
- Location
src/commands/pay.ts:18- Finding
Unverified Backend-Supplied Transactions Are Signed by the Local Wallet
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
SilkyWay appears to be a real Solana payments CLI, but it handles fund-moving authority with weak transaction-validation and key-storage safeguards.
Review before installing. Use devnet first, keep only small balances in wallets created by this CLI, protect and back up ~/.config/silkyway/config.json, do not send seed phrases or secrets through chat, and verify that SILK_API_URL/apiUrl has not been changed. Avoid unattended mainnet use until the tool validates transaction contents before signing and hardens private-key storage.
src/commands/pay.ts:18Unverified Backend-Supplied Transactions Are Signed by the Local Wallet
src/config.ts:47Wallet Private Keys Are Persisted Without Explicit Restrictive File Permissions
There is a clear mismatch between the declared description and the actual code. The description claims substantial Solana-based banking and payments capabilities, but the code chunk contains only a simple console.log statement. It does not access blockchains, wallets, payments APIs, escrow mechanisms, or any account/policy systems. The actual behavior is unrelated placeholder code rather than an implementation of the declared skill.
The declared description centers on blockchain-based banking and payment operations on Solana, including stablecoin transfers, escrow, and spending-policy accounts. The provided code chunk instead implements a generic chat client command that posts a message to a backend '/chat' endpoint and prints the response. There is no evidence in this code of payment handling, Solana interaction, escrow logic, or account policy enforcement. This is a materially different primary purpose, so it should be flagged as a mismatch.
This code does not perform the declared banking/payment behaviors. Instead, it manages a contacts/address-book feature, which is a distinct capability not mentioned in the description. While contact handling could support a payments product, this chunk’s primary behavior is unrelated to sending/receiving stablecoins, escrow transfers, or policy-controlled on-chain accounts, so the description does not accurately represent the supplied code.
The supplied code chunk does not match the declared primary functionality. The description emphasizes banking/payments features such as stablecoin transfers, cancellable escrow, and policy-limited delegated automation. This code instead focuses on wallet lifecycle utilities and test funding via a faucet. While wallet management could support a Solana payments skill, the concrete behavior here includes sensitive key generation/storage and faucet access, which are not reflected in the description. The advertised core capabilities are absent from this chunk, making this a material description-behavior mismatch.
This code chunk does not implement the declared banking/payments functionality. Instead, it manages a local contacts.json file under a config directory, validates Solana public keys, and resolves recipient names to addresses. While contact resolution could support a payment workflow, this chunk’s actual purpose is address-book management, not sending or receiving stablecoins, escrow transfers, or on-chain policy accounts. The filesystem access is also not implied by the declared description. Therefore this is a material description/behavior mismatch.
The declared description promises a Solana banking and payments capability with escrow and policy-controlled accounts. The supplied code does not implement any of those functions or access any related resources. Instead, it is a generic presentation/error-handling helper for command-line commands. While such utilities could support a larger banking skill, this chunk by itself is materially different from the declared primary purpose, so it should be flagged as a mismatch.
The lockfile pins axios 1.13.5, and the supplied advisories include high-risk issues such as SSRF-related proxy bypass and prototype-pollution-assisted MITM/credential theft scenarios. In a banking/payments skill that likely makes outbound RPC/API requests and may handle secrets or transaction metadata, an HTTP client flaw can directly affect confidentiality and integrity of payment operations.
form-data 4.0.5 is flagged for CRLF injection through unescaped multipart field names and filenames. This is exploitable only if untrusted input is used to build multipart requests, but if present it can corrupt HTTP payload structure and potentially smuggle unintended headers or fields.
ws 8.19.0 is reported to have both memory disclosure and memory exhaustion issues. In a Solana/payment context, WebSocket connections are commonly used for subscriptions and RPC streams, so a flaw in the WebSocket stack can expose process memory or allow remote denial of service.
ws 7.5.10 is also flagged for memory exhaustion DoS from tiny fragments/data chunks. Even as a transitive dependency, if any reachable WebSocket server/client path handles untrusted peers, an attacker may be able to consume memory and disrupt payment or automation workflows.
The project resolves axios to a version flagged with multiple advisories, including SSRF- and MITM-related issues. In a banking/payments agent, vulnerable HTTP handling is especially dangerous because it can expose secrets, manipulate network responses, or redirect sensitive backend interactions tied to funds movement.
The README presents live payment commands as routine examples without clearly warning that they may execute on mainnet and move real USDC. In a banking/payments skill, this increases the chance of accidental real-fund transfers by users or agents who copy-paste examples without understanding the network or wallet context.
The README states that private keys are stored locally at a specific path but does not warn that this file directly controls funds and must be protected and backed up securely. Users may leave the wallet file exposed, commit it accidentally, or fail to back it up, resulting in theft or irreversible loss of access to funds.
The skill declares no explicit tool scope or permission boundaries despite handling wallets, local config files, and remote API interactions. In an agent setting, missing scope declarations can cause the host to over-grant capabilities such as environment or filesystem access, increasing the blast radius if the skill is misused or compromised.
The documentation encourages use of mainnet-beta with real USDC and presents payment and withdrawal flows without strong transaction-safety warnings. In a high-risk financial context, users or agents may accidentally send irreversible real funds on the wrong network or for the wrong amount, causing monetary loss.
The support chat feature sends user messages and a persistent agentId to a remote service, but the documentation does not clearly warn about privacy, retention, or sensitivity of transmitted content. Agents or users may disclose wallet details, transaction intent, or operational secrets to a third party without informed consent.
This initialization flow silently generates a new Solana keypair, base58-encodes the secret key, stores it in the in-memory config object, and persists it via saveConfig without any visible warning, confirmation, or indication of secure storage. In a banking/payments skill, silently creating and writing a spend-capable private key increases the risk of users unknowingly relying on an unprotected hot wallet, accidental fund loss, and downstream compromise if the config file is exposed.
This command signs and submits a transfer transaction immediately after receiving transaction bytes from a remote API, with no explicit user confirmation, transaction preview, or independent validation of the transaction contents before signing. In a banking/payments skill, that is dangerous because a compromised or buggy backend could cause the client to sign an unintended transfer, and the user may have no chance to detect the destination, amount, or extra instructions.
The configuration file stores the entire serialized config, which includes wallet entries containing raw private keys. Because this is written in plaintext under the user's home directory without any access-control hardening, encryption, or explicit warning, compromise of the local account, backups, logs, or synced dotfiles can directly expose funds. In a banking/payments skill managing Solana stablecoins, plaintext key storage is especially dangerous because exposed keys enable immediate unauthorized transfers.
bn.js 5.2.2 is flagged for an infinite-loop vulnerability, which is typically a denial-of-service condition when parsing or processing crafted numeric input. In this package it appears transitive via Solana-related libraries, so the issue is real but likely requires attacker-controlled input reaching affected code paths.
follow-redirects 1.15.11 is reported to leak custom authentication headers across cross-domain redirects. Since axios depends on this library, requests carrying API keys, bearer tokens, or internal auth headers could expose credentials to an attacker-controlled redirect target.
stream-json 1.9.1 is flagged for O(depth^2) behavior on deeply nested input, a parser-level denial-of-service issue. This appears to be transitive via jayson and is only likely reachable if the package processes attacker-controlled deeply nested JSON streams.
uuid 8.3.2 is flagged for a missing buffer bounds check in specific UUID generation modes when a buffer argument is supplied. This is a real library flaw, but impact is limited unless the affected API variants are actually used with attacker-influenced buffer parameters.
The dependency is specified with a caret range, which allows newer minor/patch releases to be installed without explicit review. In a financial Solana skill, supply-chain drift is more dangerous because wallet, signing, and transaction behavior can change or be compromised through an upstream release.
"test": "echo \"Error: no test specified\" && exit 1"
},
"dependencies": {
"@solana/web3.js": "^1.98.4",
"axios": "^1.11.0",
"bs58": "^6.0.0",
"commander": "^12.1.0"
Axios is declared with a caret range, allowing automatic uptake of future releases, and the static analysis also indicates resolution to a known vulnerable version. In a payments-oriented agent, a compromised or vulnerable HTTP client can affect outbound API calls, credential handling, SSRF exposure, and transaction-related data flows.
},
"dependencies": {
"@solana/web3.js": "^1.98.4",
"axios": "^1.11.0",
"bs58": "^6.0.0",
"commander": "^12.1.0"
},
No suspicious patterns detected.