# You can deposit really small amount for other users to DoS them

LiquidityPool deposit/mint lacked access control, letting an attacker front-run a user's deposit with a 1 wei call to make their transaction revert.

- Payout: Audit contest
- Severity: medium
- Program: Centrifuge
- Found by: 0x3b
- Disclosed: 2023-10-11
- Write-up quality: 6/10
- Original: https://code4rena.com/reports/2023-09-centrifuge#m-04
- Library page: https://bugbountylibrary.com/r/c4%3A2023-09-centrifuge%3AM-04
- Tags: area:web3 domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:evm tech:solidity vuln:access-control vuln:business-logic vuln:dos

**Target:** LiquidityPool deposit/mint functions (processDeposit/processMint)
**Root cause:** deposit and mint call processDeposit/processMint without access control, so anyone can execute a deposit/mint for any receiver without supplying tokens, consuming the receiver's request slot.
**Steps:**
1. User submits a deposit request for the next epoch.
2. Attacker front-runs by calling `deposit(1, victim)` (or mint) with a tiny amount for the victim's address.
3. When the victim's own deposit executes, it reverts because the request was already processed / insufficient balance for the full deposit.
**How found:** Noticed deposit/mint call processDeposit/processMint which take no token value and lack access control, unlike redeem which uses withApproval; reasoned an attacker could pre-empt a user's request for free.
**Exploitation:** Attacker watches for a pending deposit request, then front-runs with a free deposit/mint call of ~1 wei targeting the victim's receiver address, causing the victim's deposit transaction to revert each epoch.
**Insight:** When a share-issuing function processes a per-receiver request without access control, check whether an attacker can consume or overwrite that request cheaply to grief the legitimate caller.