# Initial pool deposit can be stolen

Attacker frontruns Factory.createMarket to create a market with victim as initial depositor, pulling their approved tokens into an unwanted market.

- Payout: Audit contest
- Severity: high
- Program: InsureDAO
- Found by: cmichel
- Disclosed: 2022-03-15
- Write-up quality: 7/10
- Original: https://github.com/code-423n4/2022-01-insure-findings/issues/250
- Library page: https://bugbountylibrary.com/r/c4%3A2022-01-insure%3AH-04
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:race-window technique:source-review vuln:access-control vuln:business-logic

**Target:** PoolTemplate.initialize / Factory.createMarket (Solidity vault deposit)
**Root cause:** createMarket has no access control and lets the caller specify an arbitrary initial depositor (_references[4]) whose approved tokens are pulled via vault.addValue/transferFrom, so anyone can create a market that drains a victim's approval.
**Steps:**
1. Victim approves vault contract for transferFrom of amount.
2. Victim submits Factory.createMarket tx with _conditions[1]=amount, _references[4]=victim.
3. Attacker frontruns with own Factory.createMarket call using different parameters but same _conditions[1]=amount and _references[4]=victim.
4. Attacker's market creation executes first, calling _depositFrom(amount, victim) which pulls victim's tokens into the attacker-chosen market.
**How found:** Code reading of PoolTemplate.initialize and _depositFrom revealed the depositor address is caller-supplied and createMarket is unrestricted, implying a frontrun race on the approval.
**Exploitation:** Attacker observes pending createMarket tx, submits a competing createMarket with malicious/different parameters (wrong underlying, old registry) reusing the victim's amount and address, winning the race and locking the victim's approved tokens into an unwanted market.
**Insight:** When a factory/initializer accepts a depositor address as a parameter and pulls funds via transferFrom, check whether the caller is authenticated and whether a pending approval can be raced to redirect funds into attacker-chosen parameters.