# Forced buyouts can be performed by malicious buyers

A malicious buyout proposer using a contract that rejects ERC1155 tokens blocks the end() function on failed buyouts, permanently preventing new buyouts.

- Payout: Contest reward
- Severity: high
- Program: Fractional
- Credited: cccz
- Disclosed: 2022-09-27
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-07-fractional-findings/issues/212
- Library page: https://bugbountylibrary.com/r/c4%3A2022-07-fractional%3AH-02
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:source-review vuln:dos

**Target:** Buyout.sol end() function / ERC1155 transfer to proposer
**Root cause:** On failed buyout, end() pushes ERC1155 tokens to the proposer via safeTransferFrom; if the proposer is a contract that reverts on ERC1155 receipt, end() reverts and the buyout state never resets.
**Steps:**
1. Deploy attacker contract that reverts on onERC1155Received
2. Call propose()/start buyout from that contract
3. Ensure buyout fails (e.g. insufficient total supply raised)
4. Call end(); safeTransferFrom to proposer reverts, so end() reverts
5. Buyout remains active; no new buyout can be started
**How found:** Code review of end() failure path: noticed ERC1155 tokens are sent to the proposer on failure, and that a non-receiver proposer would make that transfer revert.
**Exploitation:** Attacker proposes a buyout from a non-ERC1155-receiver contract; when the buyout fails, end() cannot deliver tokens to the proposer and reverts, leaving the buyout stuck and blocking all future buyouts (griefing/DoS).
**Insight:** When a failure path pushes tokens to a user-supplied address, check whether that address can reject the token (ERC1155/ERC721 receiver hooks, ERC20 blacklists) and whether the revert bricks shared state.