Flayer — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Flayer, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 3
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 3 closed, publicly disclosed Flayer reports indexed on Coin Buggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Oracle manipulation, Logic error, across EVM-Solidity. Reading a single protocol end to end is the fastest way to see which assumptions its codebase repeatedly gets wrong, which is usually a better predictor of where the next finding lives than the category alone.
Use the vulnerability class links below to compare these findings against the same bug class in other protocols.
What reviewers look for
- Oracle manipulation findings disclosed against Flayer
- Logic error findings disclosed against Flayer
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Flayer: ````UniswapImplementation.beforeSwap()```` is vulnerable to price manipulation attack
Flayer's UniswapImplementation.beforeSwap() hook swaps accumulated collectionToken swap fees into the pool at the current spot price (fetched via getSlot0 at line 508) rather than a time-weighted average, even during the same transaction in which an attacker manipulates that price. Because Uniswap V4's delta accounting lets an attacker move the price within a single unlock callback without a flashloan, they can sell collectionTokens to drop the price, acquire the pending fee tokens at the discounted rate, then buy back the tokens to restore the price — netting risk-free profit. A provided PoC demonstrates the same 1 ether collectionToken swap costing 1.11 ether WETH normally versus only 0.41 ether WETH under the attack, and the protocol has acknowledged the issue.
Flayer: Price limit is used as the price range in internal swaps, causing swap TXs to revert
Flayer's UniswapImplementation computes internal pool swaps by calling SwapMath.computeSwapStep and passes the user-supplied sqrtPriceLimitX96 directly as the sqrtPriceTargetX96 parameter. In Uniswap V4, a price limit is the boundary at which a swap stops, whereas a price target is the input used to calculate in/out token amounts for each swap step; these are different concepts that must be translated via SwapMath.getSqrtPriceTarget. Because the internal swap uses the limit as the target, in/out token amounts are calculated against a wrong price, causing most swap transactions to unexpectedly revert. The finding was fixed by translating the price limit to a proper price range using SwapMath.getSqrtPriceTarget in the internal swap call. The impact is a DoS on swaps rather than fund loss, consistent with a medium-severity logic error.
Flayer: Lister is overpaying during the cancel of his listing on ```Listings::cancelListings()```.
Flayer's Listings.cancelListings() forces a listing owner to return the full original principal (1e18) minus only the unused portion of the prepaid tax, while ignoring that the user already paid the used tax up front (by receiving 1e18 minus tax at creation). As a result, any user cancelling a liquid listing pays the used-tax portion a second time out of pocket, sustaining a direct loss proportional to how long the listing had been live. The protocol additionally burns the full 1e18 rather than only the principal, so the double-charged fee is burned instead of routed to the UniswapV4 fee collector. The proposed fix subtracts the resolved fees from the required return amount so the user only repays principal plus the still-unused refund portion.