# CollateralManager#commitCollateral overwrites collateralInfo._amount if called with an existing collateral

CollateralManager._commitCollateral overwrites stored collateral amount for an existing asset, letting a borrower front-run lenderAcceptBid and reduce escrowed collateral to 1 wei.

- Payout: Contest reward
- Severity: high
- Program: Teller
- Credited: 0x52
- Disclosed: 2023-03-20
- Write-up quality: 7/10
- Original: https://github.com/sherlock-audit/2023-03-teller-judging/issues/170
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-03-teller%3AH-3
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:evm tech:solidity technique:race-window technique:source-review vuln:accounting-error vuln:business-logic

**Target:** CollateralManager / TellerV2 lending contract
**Root cause:** _commitCollateral assigns collateralInfo[address] = _collateralInfo unconditionally, so re-committing an existing collateral address replaces the stored amount instead of reverting or accumulating.
**Steps:**
1. Borrower commits a bid with large collateral (e.g. 100,000e6 USDC) and requests a loan (e.g. 10e18 ETH).
2. Lender calls `TellerV2#lenderAcceptBid(_bidId)`; tx enters mempool.
3. Borrower front-runs with `commitCollateral(_bidId, {USDC, amount: 1})`, overwriting stored collateral amount.
4. lenderAcceptBid executes `deployAndDeposit`, escrowing only 1 USDC while disbursing the full loan.
5. Borrower defaults; lender loses principal.
**How found:** Code review of _commitCollateral noticed the unconditional storage assignment overwriting existing collateral entries; traced that lenderAcceptBid does not let the lender specify expected collateral, enabling a front-run.
**Exploitation:** Borrower watches mempool for lenderAcceptBid, front-runs with a commitCollateral call setting the collateral amount to 1 wei, then the lender's acceptance deposits the minimal collateral and disburses the full loan amount to the borrower, who never repays.
**Insight:** When a commit/registration function writes to a mapping keyed by asset address, check whether re-committing the same key silently overwrites prior state; any accept/fill function that reads that state without caller-supplied expected values is front-runnable.