Abracadabra Money — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Abracadabra Money, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 20
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 20 closed, publicly disclosed Abracadabra Money reports indexed on CoinBuggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Front-running / MEV, Logic error, Oracle manipulation, Reentrancy, Access control, 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
- Front-running / MEV findings disclosed against Abracadabra Money
- Logic error findings disclosed against Abracadabra Money
- Oracle manipulation findings disclosed against Abracadabra Money
- Reentrancy findings disclosed against Abracadabra Money
- Access control findings disclosed against Abracadabra Money
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Abracadabra Money: Adjusting "_I_" will create a sandwich opportunity because of price changes
The MagicLP contract, inherited from the DODO Proactive Market Maker, allowed for public updates to critical pricing parameters through the setParameters function. Because these administrative calls were broadcast to the public mempool, MEV bots could front-run the transactions to perform sandwich attacks against the pool. This exploit allowed bots to extract value by trading against the price shift caused by the parameter change, ultimately draining value from liquidity providers.
Abracadabra Money: Staking contract is not able to support native USDB/WETH
The Abracadabra Money staking contract, LockingMultiRewards, was unable to account for native Blast rebasing tokens, such as USDB and WETH, when they were used as reward assets. Because the contract relied on static internal accounting to track rewards, it ignored the additional yield generated automatically by these tokens on the Blast network. As a result, this accrued yield remained inaccessible within the contract, preventing users from receiving their full potential earnings.
Abracadabra Money: Missing Return Statement in `_getReserves` Function in `MagicLpAggregator` Contract
The MagicLpAggregator contract contained a logic error in its _getReserves helper function, which failed to return data fetched from an external liquidity pool. Due to the absence of an explicit return statement, the function returned default zero values instead of the actual pool reserves. This caused the oracle to provide incorrect pricing data to any dependent system, potentially leading to financial loss or system disruption.
Abracadabra Money: Anyone making use of the MagicLP's TWAP to determine token prices will be exploitable.
The MagicLP protocol suffered from an oracle manipulation vulnerability where its time-weighted average price (TWAP) calculation was susceptible to frontrunning. Because the TWAP update logic was triggered after pool reserves had been modified, an attacker could manipulate the spot price immediately before an update, causing that manipulated price to be recorded for the entire duration of the preceding period. This allowed malicious actors to poison the oracle and trick downstream protocols into executing trades at unfavorable, attacker-controlled prices.
Abracadabra Money: Users who deposited MIM and USDB tokens into BlastOnboarding may incur losses when the pool is created via bootstrap
The Abracadabra Money onboarding process allows for the creation of liquidity pools with significantly unbalanced token reserves. Because the pool initialization mechanism fails to align reserve balances with the required pricing targets in the PMM (Proactive Market Maker) model, it creates a predictable, exploitable price curve for the initial pool state. An attacker can exploit this imbalance to perform arbitrage, extracting value from the contract at the expense of those who locked their tokens for the bootstrap phase. The issue effectively allows for the theft of funds by manipulating the starting price of a newly created pool.
Abracadabra Money: Miscalculation in addLiquidity of Router results in unauthorized spending of tokens
The Abracadabra Money Router contains a calculation flaw in its liquidity provision function that causes users to inadvertently spend more tokens than intended. By front-running a user's addLiquidity transaction with a token donation, an attacker can manipulate the contract's reported balances, causing the Router's incorrect logic to demand larger token inputs from the victim. This results in the user providing more liquidity than specified in their original transaction, effectively unauthorized spending of their assets.
All reports in this group
- Abracadabra Money: Attacker can amplify a rounding error in MagicLP to break the I invariant and cause malicious pricingReentrancy$0
- Abracadabra Money: Loss of assumed functionality of the Onboarding contract in a highly-sensitive areaAccess control$0
- Abracadabra Money: Pool Creation Failure Due to WETH Transfer Compatibility Issue on Some ChainsOracle manipulation$0
- Abracadabra Money: `LockingMultiRewards` contract on Blast does not configure gas yield nor token yield mode.Access control$0
- Abracadabra Money: User can grief bootstrap process by sending the cap amount of unlocked tokens to it.Access control$0
- Abracadabra Money: A user's tokens could be locked for an extended duration beyond their intention and without their controlLogic error$0
- Abracadabra Money: Factory::create() is vulnerable to reorg attacksFront-running / MEV$0
- Abracadabra Money: Permanent loss of yield for stakers in reward pools due to precision loss.Integer overflow/underflow$0
- Abracadabra Money: MagicLpAggregator always returns lower than correct answer, leading to arbitrage lossOracle manipulation$0
- Abracadabra Money: Tokens yeild can not be set to claimable.Logic error$0
- Abracadabra Money: Oracle price can be manipulatedOracle manipulation$0
- Abracadabra Money: Less base tokens are transferred when selling quote tokens due to the precision loss that occurred in `_GeneralIntegrate()`Integer overflow/underflow$0
- Abracadabra Money: `MagicLpAggregator` can be incompatible with potential integrators due to incorrect `latestRoundData` functionOracle manipulation$0
- Abracadabra Money: MagicLpAggregator doesn't consider the dcimal of MagicLPOracle manipulation$0