Security Incident Report: Hedera Pull-Oracle Verifier

Published: July 11, 2026 • 1:55 pm UTC

Summary

On July 11, 2026, an attacker exploited a cryptographic edge case in the on-chain verification path of Supra’s pull-oracle deployment on Hedera. The verifier did not reject the BLS identity element, represented by zero-valued curve-point coordinates, when it appeared as both the retrieved public key and the submitted signature.

The attacker constructed a proof referencing a committee identifier outside the populated committee range. That reference caused the verifier’s key lookup to produce zero-valued public-key material. The attacker supplied a corresponding zero-valued signature. Because the identity public key and identity signature form a degenerate pair that satisfies the BLS pairing equation for any message, the chain’s pairing precompile returned a successful result.

The attacker then wrote a fraudulent price for one low-liquidity pair, SAUCE/wHBAR, and used that price to borrow against overvalued collateral on Bonzo Finance, a lending protocol that consumes this feed.

Supra’s off-chain price computation, aggregation, and signing infrastructure was not compromised and did not compute or sign the fraudulent value. The vulnerability was in the on-chain verifier’s handling of identity curve points and zero-valued key lookups.

What happened

The attack combined a small genuine collateral deposit with a manufactured oracle price.

The attacker first supplied a small amount of SAUCE as collateral to Bonzo Finance. They then called Supra’s permissionless pull-oracle update function with a payload for pair 425 containing a grossly inflated price.

Permissionless relaying is an intended property of the pull-oracle design: any address may submit an update, provided that the accompanying attestation passes cryptographic verification. The vulnerability was that the verifier accepted a degenerate public-key and signature pair that did not represent a genuine Supra attestation.

After the fraudulent value was written, Bonzo valued the attacker’s SAUCE collateral far above its actual market value and permitted a borrow greatly exceeding the value of the genuine deposit. The borrow occurred seconds after the price update.

Root cause

Supra’s oracle attestations are verified on-chain using BLS signature verification over the BN254 curve. The verifier retrieves the public key associated with the committee identifier contained in an attestation and checks the submitted signature against that key through the chain’s pairing precompile.

The attacker supplied a committee identifier outside the populated committee range. The verification path did not reject that identifier before performing the key lookup. As a result, the lookup produced zero-valued public-key coordinates.

The attacker also supplied a signature encoded as the zero-valued, or point-at-infinity, curve element.

This produced a degenerate but pairing-valid combination. At a high level, the BLS verification equation compares pairings of the signature, public key, message hash, and curve generator. When both the signature and the public key are the identity element, both sides of the equation reduce to the multiplicative identity:

e(G, O) = 1 = e(O, H(m))

where O denotes the point at infinity, G the curve generator, and H(m) the hash of the message. The equality holds regardless of the message m. Consequently, the zero signature appeared to verify against the zero public key even though no legitimate signer had signed the fraudulent price.

The pairing precompile correctly evaluated the mathematical equation it was given and returned success. A pairing check over identity elements is genuinely equal to the identity, so this is spec-correct behavior for a pairing evaluator. The fault was that the verifier treated that result as sufficient evidence of a valid attestation, because it did not first reject identity-element public keys and signatures.

The vulnerability therefore consisted of two conditions:

1. A committee reference outside the populated range could yield zero-valued public-key material instead of being rejected.
2. The verifier accepted the identity element as a permissible public key and signature input.

Together, these conditions allowed the attacker to construct a proof that passed the pairing check for an arbitrary price value. No valid Supra signature over the fraudulent price existed, and the value was neither computed nor signed by Supra’s oracle network.

The fix

We have hardened the on-chain verification path so that identity elements, absent key material, and malformed curve points cannot reach or pass the pairing check.

Committee-range and key-presence validation. The verifier now rejects any committee identifier for which registered key material is not explicitly present. A lookup that would produce default zero values cannot proceed to cryptographic verification.

Identity-element rejection. Public keys and submitted signatures are explicitly rejected when they represent the zero or point-at-infinity element. This directly prevents the degenerate BLS verification condition used in the attack.

On-curve and subgroup validation. Public-key and signature points are checked to ensure that they are valid curve points in the required prime-order subgroup before they are passed to the pairing precompile.

The identity-element check alone would have prevented this attack. The additional validation layers protect against a broader class of malformed-key and malformed-signature inputs. We have also reviewed every other Supra oracle deployment that shares this verifier pattern to confirm the same guards are in place.

Scope

The impact was limited to a single asset pair, SAUCE/wHBAR (pair 425), and a single consuming protocol, Bonzo Finance on Hedera. Supra’s price computation, aggregation, and signing systems were not compromised, the corresponding push-oracle price for this pair was correct throughout, and no other feed values were affected.

Coordination

We are working directly with the Bonzo Finance Labs team on tracing the affected funds and coordinating with the relevant token issuer and exchanges on freezing and recovery where possible. We will share further updates as that process develops.

What protocols should do

As a general best practice that would have blunted the impact here, we continue to recommend that lending and derivatives protocols apply their own sanity bounds and circuit breakers on any external price input, particularly for low-liquidity assets, so that no single feed reading can move a position to an implausible valuation.

Acknowledgments

We thank the Bonzo Finance Labs and SaucerSwap teams for their rapid, collaborative investigation. We take the security of every protocol that relies on our data seriously and are committed to transparent disclosure when something goes wrong.

For technical questions, contact the Supra security team.