T05 · Unauthorized Access and Privilege Escalation
Error
- Location
- SKILL.md:42
- Finding
- Automatic Committee Joining Can Cause an Unauthorized Ancillary Stake## Vulnerability Details **File Location**: `SKILL.md`, lines 42–50 **Vulnerability Type**: Automatic financial action beyond explicitly parameterized user consent **Risk Level**: High ### Vulnerable Code ```text Step 1: Validate input and resolve proposal. Step 2: Ensure there are enough usable committee voters. Auto-join committee with minimum stake when required. Step 3: Enumerate conditions by `scope`. Step 4: For each selected condition: - If status is `CREATED`, vote to activate. - Wait until the condition is `ACTIVE`. - Add risk LP exactly once unless the user explicitly asked to top up. Step 5: Return per-condition activation and LP results. ``` ### Technical Analysis The documented input authorizes activation of proposal conditions and addition of a specified amount of risk LP. It does not include a parameter that grants permission to join a committee or defines the maximum amount that may be staked for committee membership. Despite this, Step 2 directs the agent to automatically join the committee with a minimum stake whenever additional voters are required. Committee joining is a separate financial and authorization-sensitive transaction from the requested activation and risk-LP operations. Automatically executing it violates least-privilege and explicit-consent principles. The workflow also does not require verification or confirmation of the following transaction properties: - Committee stake amount and token - Chain ID and network - Committee and proposal contract addresses - Wallet or account being used - Transaction fee limits - Aggregate maximum spend across committee staking, voting, and LP operations - User confirmation before submitting the ancillary stake Although the documentation calls the committee stake “minimum,” no numeric ceiling or validation rule is defined. The referenced execution scripts are absent from the audited package, so enforcement of any implicit safeguards c ...[truncated 1617 chars]
- Remediation
- ## Remediation Suggestions 1. Make committee joining explicitly opt-in by adding an input field such as: ```json { "allowCommitteeJoin": false, "maxCommitteeStake": "0" } ``` The secure default must be `allowCommitteeJoin=false`. 2. If committee membership is required but not authorized, stop before submitting any transaction and return a structured response describing the prerequisite. 3. Require explicit confirmation for committee joining that displays: - Chain ID and network name - Wallet address - Committee contract address - Proposal contract address - Stake token and exact amount - Estimated transaction fees - Token approval amount, if applicable - Maximum aggregate cost of the complete workflow 4. Enforce a hard `maxCommitteeStake` limit in the executable implementation. Reject the operation if the required stake exceeds that value. 5. Require a dry run before the first live execution in each environment. The dry run should enumerate every planned approval and transaction without signing or broadcasting it. 6. Separate committee enrollment, condition activation, and LP addition into individually authorized stages. Success in one stage must not imply consent for another. 7. Validate chain ID, contract addresses, token addresses, proposal identity, and expected contract bytecode against an allowlist before requesting signatures. 8. Include the referenced scripts in the audited package, or pin the package to an independently verifiable implementation version, so transaction construction and wallet safeguards can be reviewed.