# Bloom Exploit Post-Mortem: 05.09.2024

**Published by:** [Bloom](https://paragraph.com/@bloom-3/)
**Published on:** 2024-05-13
**URL:** https://paragraph.com/@bloom-3/bloom-exploit-post-mortem-05-09-2024

## Content

The following article is meant to provide a technical post-mortem and analysis of the Bloom Rebasing Yield Exploit, taking place on May 9th, 2024.SummaryOn Thursday May 9th between 2:45AM to 7:00AM UTC, there was an attack made on Bloom where the attacker exploited a net of $539,000 USDB from vault contracts. The bug was identified and then remedied about one hour after discovery.Root CauseThe exploit was due to an issue with how Blast-native yields were handled when updating cash for a position, specifically for positions that are in a loss during withdrawal. Background:Traders who are in a loss with their positions are provided extra collateral through accruing native yields over time. This feature provides the best liquidation price possible for traders, and no longer applies when positions are in profit again.Updating cash (deposit or withdrawal) helps traders adjust their leverage on positions if they want more or less risk.The core problem was located in the method updateTrade(Trade memory _t) inside of TradingStorage.sol . This method updates relevant data for an existing trade during cash deposit / withdrawals through updateMarginCallback inside of TradingCallbacks.sol . The timestamp variable that defines the pending yield accrued for a position was not being updated correctly when positions have pnl < 0. Because the timestamp wasn’t updated appropriately, this allowed the attacker to continuously withdraw USDB equivalent amounts of accrued yield on their positions over and over again.ResolutionThe UpdateMargin method was the entry point of the attack, and upon discovering the cause, the Bloom team proceeded to make an upgrade to remove the functionality from the smart contracts. The feature was effectively disabled to avoid further damage. Funds Recovery https://x.com/BloomOnBlast/status/1788695722952421689 The Bloom team was able to identify, patch, and recover 90% of exploited funds within 12 hours of the attack. The funds were reimbursed to affected LPs directly to their wallets based on a snapshot taken as of: blockNumber: 3206461 timestamp: May-09-2024 02:45:37 AM +UTC We couldn’t have done this without the help of key onchain sleuths like ZachXBT and security firms like Hexagate. Bloom recovered funds in record time for our users by negotiating a 10% bounty for the exploiter. We prioritize our user safety and will do our best to always communicate in a timely and transparent manner. Timeline of ActivityFirst Attacker’s Transaction - May-08-2024 01:28:41 AM +UTChttps://blastscan.io/tx/0x230eb03de2e95082cd6e4238ceb84e67c28ead7121e74749ee559cd9fa1f07baExploit Starts - May-09-2024 02:45:37 AM +UTChttps://blastscan.io/tx/0xbff4681a6a186d052eaf3feb722cfa0c8b285911a88e946c8a8dc5b70a86f00eExploit Finishes - May-09-2024 06:48:19 AM +UTChttps://blastscan.io/tx/0xd33be6e35ab333c704602f6f17c44b79328e972e130e9d07dd7c3f48c396b0e2Team sees reports and starts investigating suspicious on-chain activity - May-09-2024 07:21:00 AM +UTChttps://blastscan.io/tokentxns?a=0x60e329396f6dfb17f49c41dd347f7e1036e181d4Team identifies the root cause and starts drafting a fix - May-09-2024 08:05:00 AM +UTCTeam patches a fix on the smart contracts - May-09-2024 08:21:03 AM +UTCFuture Security ImprovementsWork with trusted auditors (Zellic) to address and re-implement the UpdateMargin method. (In progress)Integrate better real-time detection systems with trusted third party providers like Guardrail.ai, Hexagate, etc. (In progress)Collaborate with established security groups for crisis management / diagnosis (In progress)

## Publication Information

- [Bloom](https://paragraph.com/@bloom-3/): Publication homepage
- [All Posts](https://paragraph.com/@bloom-3/): More posts from this publication
- [RSS Feed](https://api.paragraph.com/blogs/rss/@bloom-3): Subscribe to updates