# Bounties can be broken by funding them with malicious ERC20 tokens

Anyone can fund an OpenQ bounty with a malicious ERC20 that reverts on transfer, bricking claims and locking all funds until expiry.

- Payout: Contest reward
- Severity: high
- Program: Openq
- Credited: clems4ever
- Disclosed: 2023-01-30
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-02-openq-judging/issues/62
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-02-openq%3AH-8
- Tags: domain:web3 impact:dos impact:funds-loss kind:contest platform:sherlock sev:high tech:solidity technique:source-review vuln:business-logic vuln:dos

**Target:** DepositManagerV1 / ClaimManagerV1 / BountyCore (Solidity contracts)
**Root cause:** fundBountyToken accepts any token address with no whitelist, and claimBalance uses safeTransfer on every deposited token; a token that reverts on transfer reverts the whole claim transaction.
**Steps:**
1. Deploy malicious ERC20 (MockBAD) whose _beforeTokenTransfer reverts for blacklisted addresses.
2. Attacker approves and calls `depositManager.fundBountyToken(bountyAddress, mockBAD, volume, 1, uuid)` to add the token to the bounty.
3. Attacker calls `mockBAD.setBlacklist(bountyAddress)` so transfers from the bounty revert.
4. Any `claimManager.claimBounty(...)` now reverts with 'blacklisted', bricking the bounty.
**How found:** Code review of fundBountyToken's permissive token check and claimBalance's safeTransfer loop; realized a reverting token bricks the entire claim path.
**Exploitation:** Attacker funds a bounty with a self-controlled ERC20 then blacklists the bounty address; every claim iterates all deposited tokens and reverts on safeTransfer, locking legitimate funds until expiry.
**Insight:** When a contract iterates over a user-supplied list of tokens/addresses and reverts on any single failure, an attacker can inject a poison entry (reverting token, blacklisted address) to DoS the whole batch — check for unbounded, unwhitelisted token arrays in payout loops.