Ostium Loses $18M, Bonzo Lend $9M, and BlueMove Drains Its Own Pools | Burn Notice #9
Two Oracle Failures and an Alleged Insider Backdoor, Plus a Security Vendor's npm Package Turned Infostealer.
In mid-July 2026, an attacker compromised the jscrambler npm package, a tool that developers install to secure their own code, and used it to distribute malware to the machines that installed it. Using a stolen publishing credential, the attacker released five malicious versions of the package, each of which contained an infostealer designed to extract cryptocurrency wallets, cloud credentials, and the access tokens of AI coding assistants from an affected machine. Although the incident was minor in comparison with the week’s other losses, it was representative of a broader pattern. In each of the larger incidents that followed, the point of failure was a component that a development team had built, purchased, or configured and subsequently ceased to monitor.
In today’s issue.
Ostium lost $18M on Arbitrum after an attacker compromised the private key behind its oracle signer.
Bonzo Lend lost $9.05M on Hedera when a third-party oracle verifier accepted a price update with no real signature.
BlueMove’s own team allegedly planted the backdoor that drained $400,000 from its Sui liquidity pools.
Need to Know
The week's two largest losses both originated in a protocol's dependencies, one in a compromised oracle signer key and the other in a third-party verifier's signature check. In both cases, substantial venture funding and an active user base provided no protection, because the vulnerability lay outside the code that either team had audited. A third and more unusual incident appears to have originated within a development team itself, which used a retained upgrade capability to insert a means of re-entry into its own contract. The common factor across all three is a component that each team had treated as settled, and the open question is how recently any such assumption has been tested under adversarial conditions. —Adrian
The Big One. Ostium’s $18M Oracle Signer Compromise
The news. On 15 July an attacker holding the private key behind Ostium’s oracle signer used it to feed the protocol future-dated prices and drained roughly $18M USDC from the Arbitrum perpetual exchange’s OLP vault, per Blockaid’s disclosure reported by crypto.news and CryptoTimes. On-chain tracing later pushed some estimates as high as $23.75M, and Ostium had not confirmed a final figure at the time of writing.
What broke and how. Ostium’s OLP vault settled trades against price reports from an authorised oracle signer, and it paired that signer with a registered PriceUpKeep forwarder that could trigger its own settlement calls. Holding the signer’s key handed the attacker both halves of that arrangement at once. Inside a single executeBatch transaction, the attacker opened a position at the real market price, submitted a future-dated report showing whatever price suited them, and closed the position against that invented number. Each pass through the loop compounded the margin, running the stake from $1,000 to $80,000 to $700,000 and returning as much as 900 percent a cycle, and it repeated about ten times before the vault ran dry, according to CryptoTimes. The stolen USDC was then swapped for roughly 12,084 ETH and moved through Tornado Cash, per TronWeekly.
Why it kept happening. Oracle signer compromises have become one of 2026’s most persistent attack classes, and Ostium is a reminder that money buys no immunity from them. Its $27.8M from General Catalyst, Jump Crypto, Coinbase Ventures, Wintermute, and GSR paid for a great deal, though not for any separation between the key that reports a price and the key that settles against it. The exposure was exactly that overlap. A single signer could state a price and act on it in the same breath, and a single leaked credential was enough to do both.
What to check now.
Does any single key or role hold both the ability to submit price data and the ability to trigger settlement against that data.
Are your oracle signer keys held in the same trust boundary, HSM, custody provider, or access policy, as your admin or upgrade keys, or kept separate.
Is there a sanity bound on price movement per update, independent of the signer’s own authority, that would reject a report this far from a reference price.
Would your monitoring catch ten rapid open-close cycles on one position before the tenth one clears.
Do you have a reduced-authority mode you can trigger the moment a signer’s behaviour looks anomalous, rather than only after a post-mortem confirms compromise.
A signer that can both write the price and spend against it is one leaked key away from being your protocol’s entire risk model. I would rather see that split shipped a week late than see it skipped because nobody wanted to slow down the settlement path.
— Adrian
Chain Reaction. Bonzo Lend’s $9.05M Zero-Signature Oracle Bypass
The news. Ostium was the larger of the week’s two oracle failures, but it was not the first. Four days earlier the same kind of trust broke on Hedera through a different flaw. On 11 July an attacker deposited 250 SAUCE tokens, worth a few dollars, into Bonzo Lend, then submitted a price update whose cryptographic signature was nothing but zeros, and the protocol’s Supra oracle verifier accepted it as valid, according to Bonzo’s own incident account reported by CryptoSlate and The Block. That inflated collateral let the account borrow 6.63M USDC and 34.52M wrapped HBAR, about $9.05M, within eight seconds.
What broke and how. Bonzo Lend is an Aave v2 fork and Hedera’s largest lending protocol, and like most of the network’s markets it priced its collateral through Supra rather than through logic of its own. Supra’s verifier was meant to check the signature on every price update and reject anything unsigned, but it accepted one made entirely of zeros. From there Bonzo’s lending code did what any lending code does with a price it has no reason to doubt, letting the account borrow against collateral the feed now valued far above what 250 SAUCE was worth. A legitimate Supra update overwrote the bad price soon after, and Bonzo paused the pool five minutes later, according to The Block. In the gap, a second wallet had already borrowed roughly $1M more, then identified itself as a white-hat responder and offered to return it, per The Defiant.
Why it kept happening. This is the second time in six weeks Burn Notice has covered real money lost to a third-party oracle a protocol used but never controlled, after Edel Finance in issue seven. Careful auditing of your own Solidity does not reach a bug living in a dependency’s verifier, and both protocols that lost money here had, by most measures, done real work on the code they wrote.
What to check now.
Do you treat third-party oracle contracts as part of your own audit scope, or as a black box you assume already works.
Does your protocol sanity-check an incoming price against a second independent source before acting on it.
Would a price update with a malformed or empty signature field be rejected by your own code even if the oracle’s verifier accepts it.
Do you know, today, which of your dependencies had their last security review more than a year ago.
Is there a per-transaction cap on how much a single price update can move before it triggers a pause rather than a trade.
You do not own your oracle's verifier, but you own every loss it signs off on. The teams that get burned here are the ones who treated a third-party price feed as someone else's code to worry about. Before your next release, find out who actually read the verifier you are trusting, and when.
— Adrian
Around the Forums
Humanity Protocol names the root cause, then changes direction entirely. Humanity Protocol gave the first detailed account last week of the hack Burn Notice covered in issue seven, and the cause turned out to be almost mundane. A phishing email dressed up as a Bithumb token schedule reached a developer’s laptop, according to Cointelegraph and Quantstamp’s findings reported by CryptoBreaking. Several production keys, including a quorum of the project’s multisig owners across two chains, had been sitting on that same laptop since last year’s mainnet launch, backed up once and never removed. The founder has also confirmed the project is turning toward enterprise AI products, which leaves the original decentralised-identity mission, and the security rebuild it now needs, to a much smaller team.
Will Arbitrum’s Security Council step in for Ostium the way it did for KelpDAO. Ostium’s loss revived a question the council last faced earlier this year, when it froze more than $70M after the KelpDAO exploit. Ostium’s loss is roughly a quarter that size, and Protos notes the council has not signalled whether it will step in again. Its answer will show whether it acts on the scale of a loss or on the mechanics of how the money moved.
What Else Happened
Alleged insider-planted backdoor drain of BlueMove DEX on Sui. Over 700,000 SUI, roughly $400,000 to $500,000, drained from BlueMove’s liquidity pools on 11 July, and a researcher traced the exploit to a function the project’s own upgrade-cap holder had added on 31 May, then locked in by burning that upgrade capability three days later so the contract could never be patched, per Protos and BigGo Finance. BlueMove has offered the attacker a 30 percent bounty to return the rest and says it will wind down.
ERC-4337 smart account validation flaw. Lumi Finance lost about $270,000 on Arbitrum on 13 July after an attacker exploited Sodium’s account abstraction infrastructure, mutating token allowances inside what should have been a read-only validation step, per CryptoTimes.
Supply chain compromise of the jscrambler npm package. The five bad releases behind this week’s opening went out over roughly three hours from a stolen publishing credential, on a security package that still pulls about 15,800 downloads a week, per The Hacker News and Socket’s research. JFrog tied the payload, IronWorm, to the same self-propagating lineage as last year’s Shai-Hulud campaigns, and its later versions ran on import so that a scanner skipping install scripts caught nothing.
Patch Notes
Anyone whose build pipeline or developer machines pulled jscrambler during the roughly three-hour window should treat every credential on those machines as exposed and rotate it now, the cloud keys, the CI tokens, the browser sessions, and any hot wallet sitting on the same box. Do not lean on --ignore-scripts as evidence you were safe, because the later versions ran on import. And audit a security vendor’s own package the way you would any other dependency in your build.
Long Reads
Ledger Donjon’s disclosure of a laser fault injection attack on Tangem cards, read alongside Tangem’s response. A single nanosecond laser pulse can flip one conditional check inside the card and reset its password, and because the cards carry no way to receive a firmware update, the flaw cannot be fixed on any card already in someone’s wallet. The argument around the finding is the reason to read it. Tangem’s rebuttal, that the attack needs $250,000 of lab equipment and the card in hand, holds up against Ledger Donjon’s own figures even though Donjon belongs to a direct competitor, and both sides end up right about different things.
Coinspect’s Ill Bloom disclosure, on a weak random-number generator that has been producing guessable recovery phrases in some mobile wallets since 2018. The confirmed sweep is older news, $3.14M taken from 431 of 2,114 identified addresses on 27 May, but it belongs to the same family as 2023’s Milk Sad and Trust Wallet flaws, detailed by TechTimes, and it is worth checking against any wallet your team or your users created on an unfamiliar mobile app before 2020.
Dragonfly’s Haseeb Qureshi arguing AI has not triggered a DeFi “hackpocalypse”. His evidence is that the median hack has shrunk below $500,000 this year, down from over $2M in 2025, with AI-assisted attackers picking off small and abandoned protocols while the fortified ones hold. This week reads as a complication rather than a confirmation of that case, since Ostium and Bonzo were funded, live, and well used, and between them they cleared the median many times over.
Closing Tab
Each of the week's significant losses occurred at a boundary its team had assumed was already secure, whether an oracle signer's key, a verifier's signature check, or an upgrade capability that had been left active and forgotten. None of the incidents required a novel technique. Each required only a single credential or dependency that had gone unmonitored long enough for an external party to identify it, a weakness that is now common across much of the industry's infrastructure.
Burn Notice. Operational intelligence for Web3.
Adrian Hetman