T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:3
- Finding
- Misleading Read-Only Classification Includes Financial Write Operations## Vulnerability Details **File Location**: `SKILL.md:3-11, 42-61, 93-98, 115-127, 149-170, 185-207, 221-238, 258-269, 290-309, 345-353, 391`; `README.md:3-5, 24-26` **Vulnerability Type**: Insecure and misleading skill configuration **Risk Level**: Medium The skill repeatedly identifies itself as a read-only API reference, but its instructions include numerous state-changing and financially consequential operations. ### Complete Code Snippets The declared read-only scope appears in `SKILL.md:3-11`: ```markdown description: Read-only API reference for NexusWeb3 utility protocols 11-20 on Base mainnet — scheduling, oracle, voting, storage, messaging, staking, whitelist, auctions, revenue splitting, and analytics. version: 1.1.0 homepage: https://github.com/nexusweb3dev/nexusweb3-protocols user-invocable: true --- # NexusWeb3 Utility Layer — API Reference Read-only reference for 10 utility protocols on Base mainnet. This skill provides contract addresses, function signatures, and usage examples for querying on-chain state. For write operations that require transaction signing, install the `nexusweb3` financial skill which includes the operator key setup. ``` However, `SKILL.md:42-61` documents payable scheduling and cancellation transactions: ```solidity AgentScheduler.scheduleTask{value: schedulingFee + keeperReward}( abi.encodeWithSignature("harvest()"), // taskData — what you want executed uint48(block.timestamp + 1 hours), // executeAfter — earliest execution time 0, // repeatInterval — 0 = run once 1 // maxExecutions ) // Returns: taskId uint256 totalDeposit = schedulingFee + (keeperReward * 30); AgentScheduler.scheduleTask{value: totalDeposit}( abi.encodeWithSignature("rebalance()"), uint48(block.timestamp + 1 days), uint48(1 days), // repeatInterval — must be >= 5 minutes 30 ...[truncated 5186 chars]
- Remediation
- ## Remediation Suggestions 1. Remove all state-changing examples from this package and retain only `view` or `pure` queries if it is intended to remain read-only. 2. Alternatively, rename and reclassify the skill as transaction-capable, and clearly separate read-only and write-operation sections. 3. Require explicit, operation-specific user confirmation before invoking any wallet or signing tool. The confirmation should show: - Network and chain ID. - Contract and token addresses. - Function name and decoded parameters. - ETH value and estimated gas. - Token amount and resulting allowance. - Lock duration, fee, and irreversible effects. 4. Verify Base Mainnet chain ID `8453`, deployed bytecode, and expected contract identity before preparing a transaction. 5. Query current on-chain fees and balances rather than relying on examples or assumptions. 6. Use exact, minimal ERC-20 allowances and revoke them after use where practical. Avoid unlimited approvals. 7. Simulate every write transaction and present decoded state and balance changes before requesting a signature. 8. Validate all recipient, owner, feed, poll, task, auction, split, and stake identifiers. 9. Add prominent warnings around token locks, immutable messages, persistent storage, auction bids, and non-refundable fees. 10. Include verifiable links or checked-in artifacts for contract source code, deployment metadata, and claimed security audits.