Bonzo Lend exploit: oracle accepted a zero signature

On July 11, 2026 an attacker pushed a price update for the SAUCE/WHBAR pair to the Supra oracle used by Bonzo Lend. The update carried a signature of [0, 0] and referenced committee ID 2, which had never been populated.

The verifier, requireHashVerified_V2, looked up the committee's public key. For an empty slot the lookup returned a zero key instead of failing. The pairing precompile, given zero inputs, returned true, so the forged price was accepted as signed.

SAUCE was now valued roughly 10^12 times above market. With 250 SAUCE as collateral the attacker borrowed 6,634,528 USDC and 34,518,389 WHBAR, about $9.05M. A second wallet that called itself a white hat took about $1.0M more. Bonzo paused the market at 01:41 UTC, fifty minutes after the price update.

The bug was not in Bonzo's own contracts. It was in the oracle provider's verifier, and Bonzo inherited it by trusting that verifier completely.

How to protect your protocol

Reject degenerate cryptographic inputs before the math. A zero signature, a zero public key or a point that is not on the curve must fail before it reaches a pairing check. Pairing precompiles answer the question they are asked, and for zero inputs that answer can be "valid".
A lookup that finds nothing must revert, not return a default. Reading an unset mapping slot gives zero in Solidity and most VMs. Any key, committee or config lookup should check that the slot was actually set.
Bound every external price. A lending market should refuse a price that moved by orders of magnitude since the last update, whatever its signature says. A circuit breaker on price deviation would have stopped this at the first borrow.
Treat the oracle as part of your attack surface. If an external verifier decides what your collateral is worth, its code is in scope for your audit.

Sources

Bonzo Lend incident report (preliminary)
QuillAudits analysis
Attack transaction: 0.0.995584-1783731093-686041919, EVM hash 0xd50c55e24eb8483ec55bf74e84fc9853d0f0fe36f64abdb812a2d9afa2a10a60 (HashScan)
Attacker account 0.0.10633526, verifier 0.0.4323006, Supra oracle 0.0.4323024
Fix: Supra deployed a corrected verifier to mainnet; no code reference was published.

How this was prepared: compiled from the sources above with the help of automated tools, then reviewed by the Foothold security team before publication.