The YieldBlox Exploit: How Olympix Could Have Prevented the $10M Loss
Date: February 22, 2026
Protocol: YieldBlox DAO (Blend V2 pool on Stellar)
Loss: ~$10.2M (~$3M unrecovered; ~$7.2M frozen by Stellar Tier-1 validators)
Attack Type: Price oracle manipulation via thin-liquidity market
Root Cause: Pool operator configured a VWAP oracle against a manipulable, near-zero-liquidity market with no circuit breakers or sanity checks
Overview
On February 22, 2026, a community-managed YieldBlox lending pool built on Blend V2 was drained of approximately $10.2M in USDC and XLM. The exploit did not require a smart contract bug. No reentrancy. No logic flaw. No vulnerability in Blend V2's core contracts.
This was a market design failure, and one that static analysis tooling flagged before it became a $10M incident.
Background
Blend V2 is a modular liquidity protocol on Stellar that allows operators to deploy isolated lending pools with custom asset configurations and oracle settings. YieldBlox DAO operated one such pool, accepting USTRY as collateral against borrowable USDC and XLM.
Collateral pricing for USTRY was sourced from the USTRY/USDC market on the Stellar DEX (SDEX) via Reflector, a VWAP-based oracle that calculates prices using recent trade data weighted by volume. This design works under normal conditions. In thin markets, it becomes an attack surface.
Attack Walkthrough
Step 1: Market Condition Setup
In the period immediately preceding the attack, the USTRY/USDC market on SDEX had effectively zero activity. The pool's sole market maker had withdrawn all liquidity, leaving the order book with less than $1 in hourly volume and no meaningful depth.
This created the necessary precondition: Reflector's VWAP calculation window was empty. Any trade placed would dominate the average.
Step 2: Oracle Manipulation (Tx 1–3)
The attacker operated across multiple accounts. Using one account, they placed a sell offer for USTRY at 501 USDC per USTRY, roughly 476x above fair value. Using a second account, they executed a buy against that offer, purchasing 0.05 USTRY for approximately 106.7 USDC.
This single micro-trade was enough. Because no other trades existed within the VWAP window, Reflector updated USTRY's price from ~$1.05 to ~$106.70, a 100x inflation.
The oracle was functioning exactly as designed. The problem was what it was pointed at.
Tx hashes:
Manipulation: 09e1a9d1..., 60fe039e...
Oracle update: 56466ad6...
Step 3: Collateral Inflation and Borrow Drain (Tx 4–7)
With USTRY now valued at ~$107 instead of ~$1, the attacker's holdings were treated as massively overcollateralized. They executed two borrow operations:
The inflated collateral valuation bypassed health factor checks. The attacker withdrew the entirety of the pool's borrowable reserves.
The borrowed amounts then triggered cascading liquidations across other pool participants, amplifying total damage.
Step 4: Cross-Chain Exfiltration (Tx 8–10)
The attacker bridged stolen assets from Stellar to Base (via Allbridge), BSC, and Ethereum (via Across and Relay), splitting across 31+ bridge transactions to fragment traceability.
The root cause was not oracle infrastructure failure. Reflector reported accurate prices for the data it observed. The failure was a configuration decision made at the pool operator level: routing collateral pricing through a market with no liquidity floor, no depth requirements, and no manipulation resistance.
Three compounding factors made this exploitable:
Near-zero VWAP window volume. A single 0.05 USTRY trade dominated the entire price calculation.
No liquidity thresholds or sanity checks. The pool accepted oracle updates without validating underlying market depth or detecting price deviations beyond reasonable bounds.
No circuit breakers. A 100x price spike in a single update period triggered no alerts, no pauses, no fallback pricing.
This is the canonical thin-liquidity oracle attack pattern. It has appeared before. It will appear again.
Olympix Findings: What BugPocer Caught
We ran BugPocer, Olympix's internal auditor, against the Blend V2 source. Locating the repo required some additional work since Stellar explorers only expose compiled WASM bytecode. Once we had the source, BugPocer's results were unambiguous.
Direct Match — High Severity (Verified True Positive, PoC Confirmed):
Oracle Price Manipulation — bad_debt_auction.rs, line 136
External price and oracle data are trusted without validation. pool.load_price can be manipulated via low liquidity or stale data. Recommendation: implement TWAP or staleness checks and oracle confidence bounds.
This finding maps precisely to the exploit mechanism. The oracle call was the single point of trust, and that trust was unguarded.
Supporting Findings:
Health check not enforced (actions.rs): The borrow and withdraw execution path does not internally enforce health factor validation. This is the mechanism that allowed the attacker to borrow against inflated collateral without triggering a revert.
Hard-coded LP valuation heuristic (bad_debt_auction.rs): A * 5 multiplier for 80/20 USDC/BLND pool valuation is brittle and exploitable under price divergence conditions. This is a secondary manipulation surface in auction scenarios.
Auction timing without bounds: Auction modifier logic depends solely on block difference with no upper bounds, creating additional manipulation exposure in adversarial conditions.
These findings were present in the codebase before the exploit occurred. BugPocer surfaced all of them in post-incident analysis. Had it been running in CI, it would have flagged them before a single dollar was at risk.
Recommendations
1. Replace or layer VWAP with TWAP and staleness validation.VWAP oracles are inherently manipulable in thin markets because a single high-volume trade dominates the average. TWAP (time-weighted average price) oracles spread weight over time rather than volume, making single-trade manipulation significantly more expensive. At minimum, VWAP-based oracles should be paired with staleness thresholds and cross-source validation.
2. Enforce liquidity floor requirements before accepting oracle updates.Price feeds sourced from on-chain DEX markets should validate minimum liquidity depth and minimum trade count before treating a price update as valid. A market with sub-$1 hourly volume should not be eligible as a collateral pricing source under any configuration.
3. Implement circuit breakers for price deviation.A 100x price move in a single oracle update window is not normal. Protocols should define acceptable price deviation bounds and automatically pause collateral operations when those bounds are breached, pending human review or multi-source confirmation.
4. Enforce health factor checks in execution paths, not just at entry.The finding in actions.rs points to a structural gap: borrow and withdraw paths that do not re-verify health factors internally can be exploited whenever upstream inputs (like oracle prices) are compromised. Health factor validation belongs in the execution layer, not just the entry layer.
5. Shift security left: catch vulnerabilities before deployment, not after.This attack was detectable. The oracle manipulation finding was a verified true positive with a working PoC. A system capable of catching it before deployment would have prevented the loss entirely.
Closing: Security Has to Be Continuous
The YieldBlox exploit cost $10.2M. It was not caused by an obscure zero-day or a novel attack vector. It was caused by a known class of vulnerability, thin-liquidity oracle manipulation, that static analysis tools can and do flag.
The audit-only model does not cover this gap. A point-in-time audit reviews code as it exists at one moment. Protocols evolve. Configurations change. Market conditions shift. The market maker that provided USTRY/USDC liquidity withdrew before the attack, a runtime condition no static audit could anticipate, but one that continuous monitoring can detect.
Security has to live inside the development lifecycle: in CI pipelines, in pre-deployment gates, in ongoing monitoring. Not just in a PDF delivered six weeks before launch.
Olympix provides deterministic security tooling, including static analysis, fuzzing, mutation testing, and formal verification, integrated directly into CI/CD pipelines. In post-incident analysis, BugPocer identified the oracle vulnerability in Blend V2 as a high-severity, verified true positive with a working PoC.
If you're building a lending protocol, a DEX, or any DeFi primitive that relies on external price feeds, talk to us. Security should be a property of your build process, not a retrospective after an incident.
What’s a Rich Text element?
The rich text element allows you to create and format headings, paragraphs, blockquotes, images, and video all in one place instead of having to add and format them individually. Just double-click and easily create content.
A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!
Headings, paragraphs, blockquotes, figures, images, and figure captions can all be styled after a class is added to the rich text element using the "When inside of" nested selector system.
Follow-up: Conduct a follow-up review to ensure that the remediation steps were effective and that the smart contract is now secure.
Follow-up: Conduct a follow-up review to ensure that the remediation steps were effective and that the smart contract is now secure.
In Brief
Remitano suffered a $2.7M loss due to a private key compromise.
GAMBL’s recommendation system was exploited.
DAppSocial lost $530K due to a logic vulnerability.
Rocketswap’s private keys were inadvertently deployed on the server.
Hacks
Hacks Analysis
Huobi | Amount Lost: $8M
On September 24th, the Huobi Global exploit on the Ethereum Mainnet resulted in a $8 million loss due to the compromise of private keys. The attacker executed the attack in a single transaction by sending 4,999 ETH to a malicious contract. The attacker then created a second malicious contract and transferred 1,001 ETH to this new contract. Huobi has since confirmed that they have identified the attacker and has extended an offer of a 5% white hat bounty reward if the funds are returned to the exchange.
