# Task Functionality completely sidestepped via autoWithdraw

Rigor Project's autoWithdraw sends task-cost deltas to the builder, letting a builder cycle tasks to drain all project funds.

- Payout: Contest reward
- Severity: medium
- Program: Rigor Protocol
- Credited: GalloDaSballo
- Disclosed: 2022-09-12
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-08-rigor-findings/issues/281
- Library page: https://bugbountylibrary.com/r/c4%3A2022-08-rigor%3AM-18
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** Project.sol smart contract (task/credit accounting)
**Root cause:** autoWithdraw always routes withdrawn task-cost differences to the builder regardless of whether funds originated from the Community, and only the builder signature is required for addTasks/changeOrder.
**Steps:**
1. Call `addTasks` to create a task with cost X
2. Call `allocateFunds` to allocate funds to the task
3. Call `changeOrder` with a lower `_newCost` so `_newCost < _taskCost` triggers `autoWithdraw(_withdrawDifference)`
4. Receive the delta of tokens at the builder address
5. Repeat until all Project funds are funneled to the builder
**How found:** Code reading of changeOrder's cost-reduction branch noticed autoWithdraw unconditionally sends the difference to the builder, and that addTasks/changeOrder require only the builder signature, breaking the task-system trust assumptions.
**Exploitation:** Builder repeatedly creates, allocates, and reduces task cost; each reduction triggers autoWithdraw paying the difference to the builder, draining the Project contract balance to the builder.
**Insight:** In credit/lending task systems, trace where refunded or reduced allocations are sent: if the recipient is hardcoded to one party rather than the original funder, a privileged party can round-trip create/reduce cycles to extract all pooled funds.