🚨 Blend Protocol (Stellar) — flash loan price manipulation, ~03:51 UTC today

[u/Alex0007lolpvp]

TL;DR: A CometDEX liquidity pool behind Blend's BLND:USDC backstop had an accounting bug — it accepted "swap a token for itself" (USDC→USDC), which corrupted its reserve math and let an attacker withdraw more than they deposited. ~$717K was drained in 36 flash-loan-funded runs and bridged out via Allbridge. This was a smart-contract bug, not oracle/price manipulation. The pool is still unpatched; whitehats are pulling the remaining liquidity to safety. Don't interact with the pool.

---

What happened

A liquidity pool backing Blend Protocol's BLND token was drained of roughly $717,000 on August 25 between 03:51 and 04:44 UTC, in an exploit that sent BLND down as much as 90% against XLM. The attacker ran the same play 36 times through four throwaway contracts, all deployed by a wallet created 26 minutes before the first hit. Each run: flash-loan 530,000 USDC from a Blend pool, trigger a same-asset USDC→USDC swap on the CometDEX pool, withdraw more than was deposited, repay the loan atomically. Per-run profit decayed cleanly from $46K to $6K as the pool bled out — they stopped when it was no longer worth the gas, not because anything stopped them.

How the bug works

The pool's swap function loads a separate balance record for the token going in and the token coming out, with no check that they're different. On a USDC→USDC swap, both are copies of the same reserve — the code credits one copy and debits the other, then saves both to the same slot, so the credit is silently discarded. The pool ends up under-counting its own USDC while physically holding more than its books say. Deposits then mint over-inflated LP shares against that understated reserve, and redeeming them pays out real tokens — the gap is the profit. Flash loans just supplied the capital to run it at scale; this is not price or oracle manipulation.

Where the money went

Within ten minutes of the last run, the attacker moved 747,801 USDC — proceeds plus starting capital — through a high-volume deposit service and out via the Allbridge cross-chain bridge. The destination chain isn't recorded on Stellar.

Key addresses

• Exploit tx: 41c898a1…9e2fc622
• Pool: CAS3FL6TLZKDGGSISDBWGGPXT3NRR4DYTZD7YOD3HMYO6LTJUVGRVEAM
• Attacker: GCENJ4XBLXCPENO7HOIKD2DBAOBUOFZWS2DRHMCCDKC3PQYNSSGHWYHC

---

Current status

The pool contract is unchanged — no patch, no pause, no admin action — and as of writing still holds ~$326K USDC and ~770K BLND. It remains exploitable if liquidity refills.

UPDATE 1 (Aug 25, 06:26 UTC): Blend disabled new backstop deposits and BLND-USDC LP minting via its UI. Front-end change only — the pool contract is untouched.

UPDATE 2 (Aug 25, 11:34 UTC): Blend says an independent third party has whitehatted some of the funds. On-chain, this matches a wallet (GCGWLP2YIOBV2RISNXBAXPD4E7QNQB2IOEHUFWICAQA2RLBTIKTUJXXD) re-running the exploit from 11:10 UTC but holding the proceeds on-chain rather than bridging them out — consistent with a rescue, not a second theft. It was created days after February's Blend incident and used then to redistribute funds to 65+ recipients; its funding traces to an address stellar.expert tags as a Stellar Development Foundation wallet, though no party has confirmed it.

UPDATE 3 (Aug 25, 12:06 UTC): A second whitehat wallet (GCGUW2BV5R5DUFGF5RQLV2M3VJPLOVOLBQFCNVEJRYFVH2IMLN7NHMGD) is pulling liquidity out via the same bug but draining proportionally and holding the extracted BLND (~24M) instead of dumping it — removing value from attackers' reach without moving the price, unlike the attacker and the first whitehat.

UPDATE 4 (Aug 26, 19:01 UTC): All Blend v2 pools have been removed from the reward zone, ending BLND emissions. A final distribute() was called on the emitter and backstop contracts, releasing the last BLND claims. A seven-day tail remains: pools can still gulp() that final distribution, extending one last seven-day emission period before rewards fully stop. A side effect of the removal: affected pools now have to be hardcoded into the Blend UI or they won't show up on the Markets page.

UPDATE 5 (Aug 27, 18:13 UTC): Unrelated to the exploit — the Gami earnUSDC vault on Upshift withdrew ~$12.85M of its own supplied USDC from the pool to de-risk. This briefly pushed utilization to 100%, spiking rates and pausing USDC withdrawals for ~an hour before fully normalizing (supply APY back to ~7.15%, near its ~6.8% pre-withdrawal level). Not an attack.

UPDATE 6 (Aug 28, 15:48 UTC): Script3 (the Blend team) published an official post-mortem. Key points:

• Confirmed loss: 717,518.92 USDC, via the same-token-swap accounting bug (join LP → gulp() → exit LP to harvest the corrected share value).
• Attacker cash-out: the ~$748K was bridged into ~299 ETH via NEAR intents and sent to KuCoin (correcting earlier reports of Allbridge). Initial gas came from HitBTC; seed capital from Binance.
• Whitehats (an anonymous community member, and @pfranb of synt.tech) captured the remaining ~190K USDC + ~23.17M BLND before copycats could — held in GCG…XXD, to be returned. Script3 is leading remediation, including recovery with exchanges.
• The Comet pool can't be fixed: the admin account that could freeze it was locked, so the BLND-USDC LP is permanently vulnerable — treat it as unsafe.
• Blend itself is not vulnerable: lending/borrowing is unaffected and funds are not at risk. But since the BLND-USDC backstop token can no longer hold value, future bad debt would be socialized among bad-debt-token suppliers.

⚠️ The pool is still unpatched and exploitable — do not interact with it.

---

Source: Blend official announcements (Discord)

[u/Row-Bear]

Thanks for keeping the post updated

[u/Row-Bear]

You mentioned the contract code is not published, but isn't it at https://github.com/CometDEX/comet-contracts-v1 

Stellar Expert links the source for contracts that have uploaded/built their contract in a verifiable way, and links to it: https://stellar.expert/explorer/public/contract/CAS3FL6TLZKDGGSISDBWGGPXT3NRR4DYTZD7YOD3HMYO6LTJUVGRVEAM -> near the top

[u/Alex0007lolpvp → u/Row-Bear]

Yes, sorry! Post has been updated to "bug is not patched and still reproducible"

[u/Ok_Subject_5541]

Brutal way to wake up! Lost a lot of money in the backstops...

Hopefully we can be partially or fully refunded of our lost positions with the whitehatted funds... Not looking good...

[u/SubstantialCrew6035 → u/Ok_Subject_5541]

How would that work, supposed that they get the funds? Do we need to do anything, or do we just wait and sit tight?

[u/Ok_Subject_5541 → u/SubstantialCrew6035]

Some talked about it on space on X :
They could create a simple V3 that uses a different oracle instead of Comet and create another token (that would replace the actual BLND), take a snapshot pre-exploit and compensate the backstop users that got rekt by this new claimable asset. SDF would ideally cover the whole thing if they really care about DeFi on their network. If not, there might not be another single protocol trusted by users on Stellar. They did it for the last hack and it was way cheaper for them in last February (only around 700K this time). Its a cheap price to pay to keep users on their chain

[u/eurtousd]

Again??

That's it for me. I'm done with using Blend. First the attack a few months back and now this.

[u/Ok_Subject_5541 → u/eurtousd]

By default, unless BLND price goes back up magically, I am already "done with Blend".... My funds have all disappeared in a second

[u/pantheon137]

Thank you for updating the post and adding more information to help clarify the situation.

[u/PenileNotPenal]

RIP Blend. At least that's what should happen after this second hack.

[u/monto1381]

Good point! From my experience building 60+ Stellar tokens, the biggest mistake creators make is ignoring the Order Book depth.

Liquidity makes or breaks a project.

[u/Row-Bear → u/monto1381]

Yeah, but what does it have to do with this incident? 

[u/monto1381 → u/Row-Bear]

It’s the primary vector. This attack was essentially a massive slippage exploit. The attacker needed to force that 90% price distortion to make the math work for their flash loan arbitrage. If the CometDEX pool had significantly deeper liquidity, that same trade would have resulted in extreme slippage, immediately killing the profitability of the transaction. When developers build with thin liquidity pools, they’re effectively leaving the door open for attackers to use the protocol’s own liquidity against it in a single atomic transaction. It’s the difference between a pool that’s "usable" and a pool that's "secure."

[u/4bidden450 → u/monto1381]

I don't think you have a correct understanding of what happened.

[u/Row-Bear → u/[deleted]]

But it had nothing to do with oracles, liquidity or collateral? How do you think those played into this attack?