Cowrie Research

yieldblox-ustry-sdex-reflector-order-book-oracle-manipulation-2026-02-22

12 min read

YieldBlox USTRY SDEX / Reflector Order-Book Oracle Manipulation (2026-02-22)

  • Name: YieldBlox USTRY SDEX / Reflector order-book oracle manipulation
  • Date: 2026-02-22
  • Protocol: YieldBlox DAO Pool on Blend V2
  • Chain: Stellar
  • Category: oracle manipulation / thin-order-book collateral inflation / single-venue oracle failure / isolated-pool configuration failure
  • Loss: about 10.97M, including roughly 61,249,278.31 XLM and 1,000,196.70 USDC
  • Summary: The attacker found that YieldBlox’s community-managed Blend V2 pool treated Etherfuse’s USTRY as valid collateral while sourcing its price from Reflector, which in turn read the extremely thin USTRY/USDC or USTRY/XLM market on Stellar’s SDEX. With fewer than five USTRY reportedly sitting on the ask side, the attacker pushed the quoted price from about $1.06 to about $106.74, let Reflector publish that value, and then borrowed roughly $10.9M of XLM and USDC against collateral whose real value was closer to $158k. Blend V2’s core lending logic behaved as configured; the live failure was that a pool operator let a manipulable order book define solvency for a much deeper balance sheet.
  • Trigger / entry point:
    • YieldBlox’s isolated Blend V2 pool allowed USTRY as collateral and USDC plus XLM as borrowable assets.
    • The pool used an Oracle Adapter that read USTRY from Reflector.
    • Reflector’s USTRY feed ultimately depended on a very shallow SDEX market that one actor could dominate cheaply.
  • Root cause:
    • YieldBlox treated a near-empty SDEX market as if it were a manipulation-resistant collateral oracle for a lending pool holding much deeper assets.
    • The Oracle Adapter appears to have returned the latest Reflector price for USTRY rather than a more robust aggregate or deviation-checked value.
    • Once Reflector ingested the poisoned trade, Blend’s health-factor math honored the false collateral value exactly as designed.
    • The exploit therefore was not a Blend V2 core-contract bug so much as a pool-operator risk-configuration failure: bad collateral admission plus bad oracle-source choice plus no effective anomaly guard.
  • Exploit path:
    1. The attacker identified that the affected YieldBlox DAO pool at CCCCIQSDILITHMM7PBSLVDT5MISSY7R26MNZXCX4H7J5JQ5FPIYOGYFS accepted USTRY collateral while borrowing out USDC and native XLM.
    2. In manipulation transactions 09e1a9d1197c9bf0af4e87da328c4f2d5eb49b487630aa61991fb5c1c4637cdb and 60fe039e96e88402d175c8de68e80651874ab125880dd384a1636914ba95bef1, the attacker consumed normal liquidity and placed abnormal SDEX orders that pushed USTRY from roughly $1.06 to about $106.74.
    3. Reflector oracle contract CALI2BYU2JE6WVRUFYTS6MSBNEHGJ35P4AVCZYF3B6QOE3QKOB2PLE6M then updated to the manipulated price in transaction 56466ad66cd5c49a251b9f1c7c0cf6b1b2f62d121b58ff856e2b43673b22be51.
    4. The attacker first supplied about 12,881.72 USTRY in transaction b810ba4a8d7547bb024f17b58c32cc644533176206d0f8178d4ba0a545cb7597, then borrowed 1,000,196.70 USDC in transaction ae721cacee382bdecac8d2c47286ecd42cb4711f658bb2aec7cba60dc64a31ff.
    5. The attacker then supplied about 149,876.13 USTRY total after transaction 81f304ae627ba294df0f9c0708a58a2fe770b39d65f8cd0efe1d7d6d6cc885a6 and borrowed 61,249,278.31 XLM in transaction 3e81a3f7b6e17cc22d0a1f33e9dcf90e5664b125b9e61f108b8d2f082f2d4657.
    6. Post-borrow, the attacker bridged or routed the proceeds out toward BSC, Base, and Ethereum through transactions including 1210ccb583c174e0ecb3cdc56adbc59a06d73b7ebcb07b7e9a1c0c371b9f00e3, a 15-transaction Base sequence beginning 3fba5c384763349b74c7bfece148eb12600b161faf3382ba9c1f5f0fe76d52f5, and a 16-transaction Ethereum sequence beginning 4012e2d140ea493de8d8abe5cc2ddd9e7d7f6661594d53fef5d0cfc26e1c7f0b.
  • What the attacker needed to be true:
    • USTRY had to remain admitted as collateral despite almost no executable market depth on the venue backing its oracle.
    • Reflector had to ingest the manipulated SDEX print quickly enough for the borrow path to see it as fresh truth.
    • The Oracle Adapter had to pass through the inflated latest price instead of rejecting or smoothing it.
    • The pool had to hold much deeper borrowable assets than the market depth supporting USTRY itself.
  • Technical anatomy worth remembering:
    • DK27ss’s PoC recorded Reflector returning four recent USTRY price entries where two consecutive reads were poisoned at about $106.737283 and the two earlier entries were normal around $1.0574; the adapter reportedly selected the latest value rather than a robust aggregate.
    • On the first borrow leg, about 12,881.72 USTRY was treated as roughly $1.375M of collateral, allowing a 1,000,196.70 USDC borrow with a reported health factor around 1.3557; at the real price, the same collateral would have been worth only about $13.6k and the health factor would have failed.
    • On the second leg, about 149,876.13 USTRY was treated as roughly $15.997M of collateral, enough to support combined debt around $10.87M; at the real price, the same position was worth only about $158.5k.
    • This is a clean price printed here, value withdrawn there lending incident: the attacker did not need to steal or mint fake USTRY; they only needed YieldBlox to believe the printed order-book price long enough to honor it as XLM and USDC borrowing power.
    • The case is also a useful reminder that order-book VWAP or last-price logic is not automatically safer than AMM spot reads. If the market is empty enough, one actor can become the market.
  • Representative transactions and addresses:
    • Manipulation transaction 1: 09e1a9d1197c9bf0af4e87da328c4f2d5eb49b487630aa61991fb5c1c4637cdb
    • Manipulation transaction 2: 60fe039e96e88402d175c8de68e80651874ab125880dd384a1636914ba95bef1
    • Oracle update transaction: 56466ad66cd5c49a251b9f1c7c0cf6b1b2f62d121b58ff856e2b43673b22be51
    • Supply transaction 1: b810ba4a8d7547bb024f17b58c32cc644533176206d0f8178d4ba0a545cb7597
    • Borrow transaction 1 (USDC): ae721cacee382bdecac8d2c47286ecd42cb4711f658bb2aec7cba60dc64a31ff
    • Supply transaction 2: 81f304ae627ba294df0f9c0708a58a2fe770b39d65f8cd0efe1d7d6d6cc885a6
    • Borrow transaction 2 (XLM): 3e81a3f7b6e17cc22d0a1f33e9dcf90e5664b125b9e61f108b8d2f082f2d4657
    • Victim pool: CCCCIQSDILITHMM7PBSLVDT5MISSY7R26MNZXCX4H7J5JQ5FPIYOGYFS
    • Oracle adapter: CD74A3C54EKUVEGUC6WNTUPOTHB624WFKXN3IYTFJGX3EHXDXHCYMXXR
    • Reflector oracle: CALI2BYU2JE6WVRUFYTS6MSBNEHGJ35P4AVCZYF3B6QOE3QKOB2PLE6M
    • Main attacker address highlighted in public analyses: GBO7VUL2TOKPWFAWKATIW7K3QYA7WQ63VDY5CAE6AFUUX6BHZBOC2WXC
    • EVM-side receiver address highlighted by BlockSec: 0x2d1ce29b4af15fb6e76ba9995bbe1421e8546482
  • Response / mitigation:
    • Script3 said the issue was isolated to one community-managed pool and not a Blend V2 core-contract vulnerability.
    • Tier-1 Stellar validators reportedly froze about 48M XLM, roughly four-fifths of the stolen native asset flow, while the attacker continued trying to launder remaining proceeds.
    • Script3 later said pool depositors would be compensated for the bad debt.
    • The broader fix is harsher than change the oracle: if a collateral asset has near-zero executable depth on the venue behind the feed, it should not sit in the solvency core without severe caps or outright exclusion.

Pattern tags

  • Thin-book print promoted into collateral truth: YieldBlox let a marginal SDEX trade on a market with almost no executable ask depth stand in for what this collateral is worth to a lending system.
  • Single-venue price publication failure: Reflector plus the Oracle Adapter appear to have passed one manipulable local venue straight into solvency math instead of forcing a stronger independent root, a depth floor, or a degraded-mode fallback.
  • Cross-liquidity-domain reserve spending: the venue printing USTRY truth was tiny, but the venue paying that truth out was a much deeper XLM and USDC lending book, so local quote manipulation turned into external balance-sheet loss.
  • Same-mark immediate monetization: once the inflated USTRY price landed, the same mark immediately supported borrow power with no meaningful cooldown, staged cap expansion, or route-local skepticism between new price published and deep assets leave.

Three thin-book price-authority promotions this incident collapsed

  1. A local order-book print exists at all

    • Some SDEX USTRY trade cleared, and Reflector plus the adapter could observe a fresh venue price.
    • This is only the existence question: there is some market-shaped object the pool might later read.

  2. That print deserves to count as canonical collateral truth for this exact lending market

    • YieldBlox still had to prove that one shallow venue was manipulation-resistant enough, independent enough, and deep enough to stand in for what USTRY is worth inside Blend health-factor math.
    • This is the solvency-truth question: this local print really deserves to become collateral value, not merely the oracle returned a number.

  3. That accepted collateral truth deserves immediate borrow authority against this much deeper reserve book

    • Even if the pool briefly accepted the mark, it still had to decide how much USDC and XLM that mark could release before any second boundary engaged.
    • This is the authority-budget question: this accepted price really deserves this much same-window reserve authority.

Why the exploit worked

  • YieldBlox let a tiny local market define system-relevant collateral truth. The SDEX book behind USTRY did not need to be globally wrong; it only needed to be locally empty enough that one actor could become the market long enough for Reflector to publish a solvency-critical lie.
  • The isolated-pool framing did not actually isolate the danger. Pool operators had still given USTRY immediate authority over a balance sheet holding much deeper USDC and XLM, so a shallow collateral venue could print borrow power against assets whose exit liquidity lived somewhere else entirely.
  • Reflector and the Oracle Adapter appear to have consumed the manipulated print as fresh truth instead of treating it as an anomaly relative to executable depth, recent history, or independent venues. That meant the protocol promoted a thin-book quote directly into health-factor math.
  • The attack also had no meaningful second boundary after price publication. Once the inflated USTRY mark landed, the same price immediately supported a first USDC borrow, a larger follow-on USTRY supply, and then the much larger XLM borrow. YieldBlox did not force time, size, or route-local skepticism between new price printed and deep assets leave the pool.
  • This is why the incident is sharper than generic order-book oracle risk: the failure was not just bad data, but letting a manipulable venue, a pass-through adapter, and a deep borrow book share one undifferentiated solvency object.

Detection and audit pivots

  • Compare oracle-backed collateral capacity against executable order-book depth, not just reported market price. If moving the feed by 10x or 100x costs far less than the assets borrowable against it, the market should already be in quarantine.
  • Reconstruct the whole publishing path: which SDEX pair moved, what Reflector read, how many samples the feed kept, whether the adapter selected latest versus a robust aggregate, and how quickly the new mark became borrow power.
  • Force thin-book shock tests in staging: consume most of the ask side, print an absurd last trade, then ask whether the pool would still accept the collateral at face value.
  • Review isolated pools as balance-sheet products, not as mere deployment topology. Isolation only helps if collateral, oracle, borrow caps, and withdrawal throttles all assume the collateral venue can fail independently.
  • Alert on collateral notional / visible executable depth ratios, abrupt single-update repricings, and cases where one small initial borrow materially expands what the attacker can do on a second leg.

Failure-prevention checklist

  • Do not admit collateral whose backing oracle depends on a venue with negligible executable depth relative to the assets that can be borrowed against it.
  • Require independent price roots or strong degraded-mode behavior for exotic collateral. If the feed is effectively one thin local market, treat it as a soft signal, not immediate solvency truth.
  • Make oracle adapters explicit about selection logic: latest print, median, TWAP, depth filter, deviation clamp, and fallback path should all be machine-checkable and economically justified.
  • Put borrow-side quarantine under newly listed or thinly traded collateral: low caps, collateral factor 0, delayed activation, or per-asset ceilings until depth and oracle quality are proven over time.
  • Bind route-local release controls to oracle confidence. Even if a price is accepted temporarily, one update should not unlock uncapped USDC and XLM outflows from the same pool.
  • Monitor and clamp extreme repricings coming from one venue, especially when the collateral venue and borrowable assets have radically different liquidity quality.
  • Treat community-managed pool configuration as custody code. Framework is sound is not a defense if the live pool operator can wire shallow collateral into deep-liquidity reserves without hard guardrails.

Audit prompts

  • How much real executable depth sits behind the exact venue or venues this collateral feed trusts, and how does that compare with maximum borrowable value from the pool?
  • If one actor consumes most of the visible ask side and prints a new marginal trade, what exact step prevents that print from becoming collateral truth?
  • Does the adapter consume latest, a time-weighted value, a depth-weighted value, or a bounded aggregate, and can reviewers prove that from code rather than from docs?
  • What independent venue, issuer redemption path, or offchain reference can contradict a clearly absurd local order-book price before the pool lends against it?
  • What pool-local caps, pauses, or staged withdrawals still apply after a suspicious oracle update lands but before operators intervene?
  • If this is called an isolated pool, isolated from what exactly: contagion to other pools, or also from local collateral-market failure turning into immediate deep-asset loss?
  • Which party is responsible for proving that a listed collateral asset remains mature enough to stay in the solvency core: framework maintainers, pool operators, token issuers, or oracle operators?

Lessons that should already be standard

  • A thin order book is not a price oracle just because it is onchain and queryable.
  • Oracle returned a number is not the same claim as this venue proved collateral truth for a lending market.
  • Accepted collateral truth is not the same claim as this mark deserves immediate authority over the pool's deepest borrowable reserves.
  • Isolated pools do not neutralize oracle risk; they only localize it if collateral admission, borrow caps, and degraded-mode controls are equally local and equally strict.
  • Latest market price is often the wrong question. The real lending question is whether the market behind that price can absorb liquidations or collateral exits anywhere near the size the protocol is willing to honor.
  • Community-managed configuration is still protocol risk when users lend real assets into the pool. Governance locality does not reduce the need for hard oracle and collateral guardrails.
  • If one venue can print the number and a deeper unrelated reserve pays out against it immediately, the protocol has already fused two very different liquidity realities into one dangerous solvency story.

Why this incident matters

  • It is a crisp order-book oracle exemplar, distinct from AMM reserve-ratio attacks like Polter and distinct from protocol-native governance-token cases like Moola or Inverse.
  • It shows that isolated-pool lending designs do not eliminate oracle risk; they relocate it into per-pool collateral and oracle configuration choices.
  • It is also a good case study in responsibility boundaries: Blend V2 as a framework may have worked as designed, but users still lost funds because the live operator-configured oracle path let a ghost-town market define real borrowing capacity.

Internal linkages

Control surface

  • The leverage sat in pool-level collateral admission, pool-level oracle selection, Reflector adapter behavior, and the decision to lend deep XLM and USDC liquidity against a collateral mark backed by an almost empty order book.
  • The quiet mistake was not an oracle got hacked. It was letting a market with almost no executable depth decide how much real balance-sheet value could leave the pool.

Sources

Last reviewed

  • 2026-07-29 UTC

Graph View

Backlinks