# CollateralManager#commitCollateral can be called by anyone

CollateralManager.commitCollateral lacked access control, letting anyone attach malicious collateral to any bid and ransom locked funds.

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

**Target:** CollateralManager smart contract (commitCollateral)
**Root cause:** commitCollateral is public with no check that the caller is the borrower, an approved forwarder, or TellerV2, so arbitrary callers can commit collateral to any bidId.
**Steps:**
1. Attacker deploys malicious ERC20 that transfers once then pauses and returns uint256.max from balanceOf
2. Victim creates bid: 10e18 ETH against 50,000e6 USDC at 10% APR
3. Lender calls `TellerV2#lenderAcceptBid` to fill the bid
4. Attacker front-runs with `CollateralManager#commitCollateral(bidId, [maliciousToken])`
5. Malicious token pauses, breaking liquidation and full repayment
6. Attacker ransoms locked tokens, unpausing only when paid
**How found:** Code review of commitCollateral revealed no caller restriction; auditors reasoned anyone could pass any bidId and crafted a griefing/ransom scenario with a pausable token.
**Exploitation:** Front-run lenderAcceptBid with an unauthenticated commitCollateral call injecting a pausable malicious token, then hold the loan hostage via broken liquidation/repayment until ransom is paid.
**Insight:** On lending protocols, audit every public function that mutates per-bid state (collateral, terms) for caller authorization—front-running bid fills with attacker-controlled collateral is a viable griefing vector.