# Potential griefing with DoS by front-running vault creation with same vaultID

User-supplied vaultID in Yield's Cauldron build() lets an attacker front-run a victim's batch tx, squat the vaultID, and DoS vault creation.

- Payout: Audit contest
- Severity: medium
- Program: Yield
- Disclosed: 2021-07-23
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2021-05-yield-findings/issues/43
- Library page: https://bugbountylibrary.com/r/c4%3A2021-05-yield%3AM-01
- Tags: area:web3 domain:oss domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:evm technique:race-window vuln:business-logic vuln:dos

**Target:** Cauldron/Ladle batch vault build() on-chain contract
**Root cause:** build() accepts a user-specified vaultID instead of assigning it in-protocol; Cauldron.sol Line180 reverts if the vaultID already exists, so a squatted ID blocks the legitimate build.
**Steps:**
1. Victim submits a batch tx calling `build()` with a chosen `vaultID` via the Yield front-end.
2. Attacker observes the tx in the mempool and reads the `vaultID`.
3. Attacker submits a batch tx with only the build operation using the same `vaultID` at a higher gas price to front-run.
4. Cauldron assigns the `vaultID` to the attacker; victim's tx later reverts on the Line180 existence check, failing the whole batch.
**How found:** Reading build()/Cauldron logic: noticed vaultID is caller-supplied and existence-checked, making it a predictable mempool-observable value an attacker can pre-empt.
**Exploitation:** Attacker front-runs each observed build() with a minimal build-only batch at higher gas, paying gas to squat the vaultID; victim's entire batch reverts, preventing vault creation and protocol interaction.
**Insight:** When an identifier is caller-supplied and uniqueness-checked on-chain, treat it as a front-runnable namespace: any mempool-visible create with a chosen ID can be squatted cheaply to DoS the legitimate caller.