# Factory.create: Predictability of pool address creates multiple issues.

Factory.create derives clone address solely from user-supplied salt, letting an attacker frontrun to hijack deposits or grief pool creation.

- Payout: Contest reward
- Severity: medium
- Program: Caviar
- Credited: AkshaySrivastav
- Disclosed: 2023-05-18
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2023-04-caviar-findings/issues/419
- Library page: https://bugbountylibrary.com/r/c4%3A2023-04-caviar%3AM-11
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:race-window technique:source-review vuln:access-control vuln:business-logic vuln:dos

**Target:** Factory.create / PrivatePool clone deployment (Solidity)
**Root cause:** cloneDeterministic uses only the user-supplied _salt, so the resulting pool address is fully predictable and not bound to the creator; anyone can deploy at that address first.
**Steps:**
1. User broadcasts create(salt=XXX) then deposit txns.
2. Attacker sees salt in mempool and frontruns with factory.create using same salt XXX, becoming owner of the pool at the predicted address.
3. User's create reverts (DeploymentFailed) but deposit tx succeeds into attacker's pool.
4. Attacker calls pool.withdraw to drain the deposited ETH.
5. Alternatively attacker repeats frontrun create to grief/DoS Factory.create.
**How found:** Noticed create uses cloneDeterministic(_salt) with only user-controlled salt, making address predictable from public mempool data; wrote Foundry PoCs for theft and DoS.
**Exploitation:** Mempool observation of _salt, frontrun create to occupy the deterministic clone address, victim's deposit lands in attacker-owned pool, attacker withdraws funds as owner.
**Insight:** When a factory uses CREATE2 with a user-supplied salt, check whether the salt is bound to msg.sender; unbound salts let frontrunners squat the deterministic address and capture follow-up deposits.