T09 · Insecure Skill Coding Practices
- Location
src/cli/transfer-sol.ts:49- Finding
Confirmed Network Is Not Bound to the RPC Endpoint Used for Transfer Execution
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill appears to send SOL as advertised, but it should be reviewed because it can make irreversible transfers with a funded key without binding the user-confirmed network to the RPC endpoint used at execution.
Review this carefully before installing. Use a dedicated low-balance wallet, test on devnet first, do not expose SOLANA_PRIVATE_KEY in chat or logs, and avoid mainnet transfers unless you have independently verified the exact RPC endpoint and recipient. The publisher should add a required network argument and fail closed if the connected cluster does not match the confirmed network.
src/cli/transfer-sol.ts:49Confirmed Network Is Not Bound to the RPC Endpoint Used for Transfer Execution
The declared description says the skill sends native SOL on Solana using a signing key and network configuration. The provided code does not perform any transfer-related action. It only constructs a Solscan transaction URL for a given signature and cluster. That is a materially different primary purpose from sending SOL, so this is a clear description-behavior mismatch.
The supplied code chunk is a static constants module for identifying Solana clusters by genesis hash. It does not implement fund transfers, transaction signing, recipient handling, or RPC-based SOL movement as described. This is a materially different primary purpose from the declared skill description, so it should be flagged as a mismatch.
The declared purpose centers on sending native SOL, which would require building and submitting a transfer transaction with a signer and recipient. This code chunk only provides connection setup and cluster inference utilities. While these may support a transfer skill, they do not themselves perform the declared primary action. Therefore, the supplied code does not accurately represent the declared behavior.
This code chunk does not implement SOL transfer behavior. It merely generates a Solscan link for viewing a transaction by signature, with minor cluster handling. That is materially different from the declared purpose of sending SOL using a signing key and network configuration. The primary purpose and capabilities are therefore mismatched.
The declared description says this skill transfers native SOL using a funded signer and appropriate RPC/network selection. The provided code does not implement any transfer behavior, key handling, RPC calls, or transaction submission. It only contains static type/constant definitions for mapping genesis hashes to Solana cluster names, including testnet. This is a materially different primary purpose from sending SOL, so the description does not accurately represent this code chunk.
Referenced artifact was not completely inspected
From the directory that contains this `SKILL.md` (skill root), after `npm install`:
The lockfile includes ws 8.20.0 via rpc-websockets, and the cited advisories indicate memory disclosure and memory-exhaustion denial of service in websocket handling. Because Solana clients commonly maintain websocket connections to RPC infrastructure, a vulnerable ws version is relevant to this skill's network-facing behavior and could expose process memory or crash the service if a malicious or compromised endpoint interacts with it.
The lockfile includes ws 7.5.10 via jayson, and the advisory describes memory-exhaustion denial of service through crafted websocket fragmentation/chunking. Even though this appears transitive, websocket parsers are directly exposed to network input, so a reachable malicious peer could consume memory and destabilize the agent process.
The skill declares use of a sensitive environment variable (SOLANA_PRIVATE_KEY) but does not define any explicit tool scope or permissions boundary. In an agent setting, missing scope restrictions can allow broader-than-expected secret exposure or command execution pathways around a high-risk blockchain transfer workflow.
This code accepts raw private key material, parses it, and constructs a usable keypair, but there is no confirmation prompt, warning comment, or user-facing disclosure in the file about the sensitivity of the input. Handling secret keys is safety-critical because it directly involves credentials that can control funds or accounts if exposed or misused.
This function performs an irreversible on-chain SOL transfer immediately once called, with no built-in confirmation, policy check, or human-approval control at the point of spend. In an agent setting, if upstream prompt parsing, recipient resolution, or amount selection is manipulated or mistaken, the code will still sign and broadcast the transaction using a funded key, which can directly cause loss of funds.
The lockfile includes uuid 11.1.0 via rpc-websockets, and the cited issue affects uuid v3/v5/v6 when a caller provides a destination buffer. In this package-lock alone we cannot prove the vulnerable code path is exercised, but inclusion of a version with a known defect is still a real supply-chain risk because dependent code may invoke the affected API during runtime.
The lockfile includes stream-json 1.9.1 through jayson, and the cited issue is an algorithmic complexity problem on deeply nested input. This is a real dependency weakness, but in this skill it appears only transitively and is less likely to be exposed unless untrusted nested JSON is processed through the affected filter components.
The lockfile includes uuid 8.3.2 via jayson, and the same missing bounds-check issue affects certain UUID generation variants when a buf argument is supplied. Although exploitability depends on whether that specific API usage occurs, shipping a dependency version with a known defect is a legitimate vulnerability finding rather than a false positive.
The dependency uses a caret version range, which permits automatic installation of newer minor/patch releases rather than a single audited version. In a skill that signs and submits native SOL transfers, a compromised or malicious upstream package release could directly affect transaction construction, key handling, or destination logic, making supply-chain risk more consequential than in a non-financial tool.
"transfer": "npm run build --silent && node dist/scripts/transfer-sol.js"
},
"dependencies": {
"@solana/web3.js": "^1.98.0",
"bs58": "^6.0.0"
},
"devDependencies": {
The bs58 package is referenced with a non-exact version range, allowing upstream changes to be pulled in during future installs. Because this skill likely uses base58 decoding/encoding for Solana addresses or private key material, a tampered dependency could influence sensitive wallet operations or redirect funds indirectly through malformed key/address handling.
},
"dependencies": {
"@solana/web3.js": "^1.98.0",
"bs58": "^6.0.0"
},
"devDependencies": {
"@types/node": "^24.5.2",
Dependencies lack version pinning, allowing potential malicious package updates. Consider pinning versions.
"bs58": "^6.0.0"
},
"devDependencies": {
"@types/node": "^24.5.2",
"typescript": "^5.9.2"
}
}
Dependencies lack version pinning, allowing potential malicious package updates. Consider pinning versions.
},
"devDependencies": {
"@types/node": "^24.5.2",
"typescript": "^5.9.2"
}
}
No suspicious patterns detected.