Rubicon — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Rubicon, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 2
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 2 closed, publicly disclosed Rubicon 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 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
- Logic error findings disclosed against Rubicon
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Rubicon: Incorrect fee handling in `Position.sol's` Market `Buy`/`Sell` functions
Rubicon's `Position.sol` helpers `_marketBuy` and `_marketSell` pre-calculate the market fee and inject it into their order sizing before routing through `RubiconMarket`, which already accounts for the same fee on v2 trades. The result is double (incorrect) fee accounting that yields improper fee deductions and wrong trade execution whenever a user opens or closes a leveraged position via the swap path. The sponsor confirmed fees should not be handled in these helpers, and the judge reduced the severity to Medium after noting that the wider `RubiconMarket` fee logic contains many errors. The finding was reported by many participants and consolidated as a duplicate group led by issue #282.
Rubicon: `Position` contract allows to interact with positions that are liquidated
Rubicon's Position helper lets a borrower add collateral to a lending position even after that position's collateral has already been liquidated. Because the position records its collateral quantity at creation and closePosition must redeem exactly that amount from the Position contract's own bathToken balance, a margin increase requested just after liquidation mints new bathTokens that can never be withdrawn — the redeem amount permanently exceeds what the contract holds. The confirmed result is that the additional collateral is locked forever, usable only as borrowing collateral, representing a direct loss for the user.