Q1 2026 - $130M+ lost in DeFi attacks: what broke, how it worked, what it cost

Overview, key trends analysis, and technical breakdown of five of the main DeFi exploits — insights from a security researcher.

--

Press enter or click to view image in full size

It’s only Q1 2026, and DeFi attacks have already exceeded $137 million in total losses. Integer overflow. Oracle manipulation. Reentrancy. Flash loan abuse. A compromised key.

We sat down with Vladislav Yaroshuk, security researcher at Consensys Diligence, and analyzed five of them — selected for the depth of their attack mechanics and the scale of their impact.

Press enter or click to view image in full size

Article structure: To help readers navigate the density and technical complexity of the exploit, the article opens with a trend analysis of Q1 2026 exploit patterns, then offers for each hack a concise TLDR, an attack sequence, and the main takeaways.

Pick your preferred depth.

Hacks analyzed:

- Truebit ($26.6M),

- YieldBlox ($10.97M),

- Makina Finance (~$4.13M)

- Solv Protocol ($2.73M)

- Resolv (~$25M).

Exploits trends— what the data tells us

• Design correctness has the greatest impact: The dominant risk in 2026 is not a rare, highly technical bug, but rather logic and validation mistakes. How a protocol is designed, how it checks inputs, or how its rules are enforced. This category accounts for the majority of losses, both in count and in dollar value. Thorough review before and after deployment remains the single most effective line of defense.
• Strong Prevention Is the Foundation of Security: Of $137.7M exploited, roughly $9M was recovered — about 6.5%. This shows that prevention is far more effective than recovery. Establishing robust prevention, recovery, and incident response readiness as industry standards is essential to avoid major losses.
• A small number of large exploits drive most losses: The top 4 incidents alone account for about $91.9M, roughly two-thirds of total losses, showing that high TVL protocols are prime targets for blackhat hackers.
• Ethereum stands out as the main target: Its position as a leading ecosystem with many high-value protocols makes it the primary focus for attackers.

Press enter or click to view image in full size

• Cross-chain protocols require specialized security review: Multiple-chains system, such as SwapNet, CrossCurve and IoTeX, expand trust assumptions, increase validation complexity, and introduce edge cases that single-chain protocols don’t face. Their complexity demands architecture-specific security models.
• Oracle-related risks are still prevalent: Oracle manipulation, oracle misconfiguration, and price dependency together form a significant share of losses. Protocols that commit to robust price validation (deviation checks, liquidity thresholds, multi-source feeds) reduce their exposure to one of the most persistent attack categories. Oracle integrity is a design priority.
• Key compromise remains a top-tier operational risk: Only two incidents involve compromised private keys, but one of them is the single-largest loss on the chart. Operational security issues occur less frequently than logic bugs but are catastrophic when they fail.
• Classic reentrancy persists, but it is not the primary pattern: Reentrancy is identified in only one instance/case. It suggests that the main drivers of 2026 losses are higher-level business logic and validation mistakes.

Press enter or click to view image in full size

A final higher-level takeaway — TLDR: In 2026, DeFi security is shifting from traditional vulnerability classes to higher system-level correctness: permissioning, validation, mint/burn invariants, pricing assumptions, and cross-chain message handling. Teams aligning their security focus accordingly will be better prepared for emerging threats.

A note: this is a curated snapshot of exploits exceeding $1M, not all incidents. It shows directional trends rather than precise ecosystem-wide statistics.

The five exploits that follow put several of these patterns under a microscope.

At a Glance: Exploits technical breakdown

1. Truebit — Integer Overflow — $26.6M

Date: January 8, 2026
Chain: Ethereum
Attack vector: Integer overflow in bonding curve pricing function

TLDR: The contract’s pricing math returned zero when fed one carefully crafted number. The attacker minted tokens at no cost and sold them for $26.6M in ETH.

Truebit’s bonding curve contract was compiled with a Solidity version below 0.8.0 — meaning arithmetic operations had no built-in overflow protection. The contract had been deployed roughly five years earlier and was still holding significant value.

The attackers computed a precise input that caused the pricing function to overflow, forced a zero price, minted billions of TRU tokens for free, and sold them back into the pool for ETH. Repeating this buy-sell cycle five times and recalculating the overflow threshold as the pool drained, they extracted 8,535 ETH across the iterations.

A second attacker exploited the same path minutes later, extracting an additional $224K. Total impact: ~$26.6M lost.

Attacker execution sequence:

1. First, the attacker computed the exact amount for which getPurchasePrice(amount) would overflow uint256 and return 0, given the current pool reserve and totalSupply.
2. Next, buyTRU(amount) was called with 0 ETH, triggering mint to issue billions of TRU tokens to the attack contract at no cost.
3. Then, after approving the pool contract, sellTRU(amount)was called, executing transferFrom and burn on the TRU token and sending thousands of ETH back to the attack contract.
4. This buy-sell cycle 4 was repeated four more times, with the overflow threshold recalculated each round as the reserve shrank, until the pool held under 0.1 ETH.
5. Finally, 8,535 ETH profit was forwarded to the attackers’ wallet.

Takeaway: Old contracts compiled without overflow protection remain live and funded. Attackers are actively scanning for legacy deployments.

2. YieldBlox — Oracle Manipulation — $10.97M

Date: February 22, 2026
Chain: Stellar
Attack vector: VWAP oracle poisoned via near-zero-volume market

TLDR: A token’s price was determined by trades on a nearly empty market — one trade in an illiquid market was enough to convince the system that a $158K deposit was worth $16M, and the attacker borrowed $11M against it.

YieldBlox sourced its USTRY price from the Stellar DEX through a Reflector oracle using a volume-weighted average. The USTRY/USDC market had hourly volume under $1 and fewer than 5 tokens on the ask side.

This wasn’t a single point of failure — it was four weak links compounding. An illiquid collateral market (under $1 in hourly volume, fewer than 5 tokens on the ask side). A VWAP oracle sampling with near-zero volume. An adapter that passed the price to Blend V2 without deviation checks or liquidity thresholds. And a lending protocol that accepted the poisoned price directly into its health factor calculation.

The attacker placed a sell offer at 100x the real price through a burner account, then triggered it with a tiny buy — the only trade in the VWAP window. The reported price jumped from ~$1.06 to ~$106.74. With no circuit breaker, Blend V2 valued the attacker’s 153,000 USTRY collateral at ~$16M instead of ~$158K and approved two large borrows.

The attacker then swapped the stolen assets to USDC, bridged them to Base via Allbridge, and moved them to Ethereum via Across and Relay. Blend V2 had been formally verified one year earlier. The oracle integration was explicitly outside the scope of that verification.

Attacker execution sequence:

1. Created three Stellar accounts over eight days: a primary borrowing wallet, an SDEX burner for the inflated offer, and a trigger account to execute the price-setting trade.
2. Placed a sell offer for 1.2185 USTRY at 107 USDC per token — 100x the real price — through the burner account on the SDEX.
3. Bought 0.05 USTRY against that offer through the trigger account, making it the only trade in the Reflector VWAP window and locking the oracle price at $106.74.
4. Deposited 13,003 USTRY as collateral into the YieldBlox pool and borrowed 1,000,196 USDC against the inflated valuation.
5. Deposited an additional 140,000 USTRY and borrowed 61,249,278 XLM against a now-$15.99M phantom collateral position.
6. Swapped stolen assets to USDC, bridged to Base via Allbridge, and moved to Ethereum via Across and Relay.

Takeaway: Formal verification of core logic doesn’t cover integration risk. An oracle feeding unvalidated prices from an illiquid market into a lending protocol is a design-level failure.

3. Makina Finance — Oracle Manipulation + Flash Loan — ~$4.13M

Date: January 20, 2026
Chain: Ethereum
Attack vector: Permissionless AUM update combined with flash-loan-inflated spot prices

TLDR: The protocol’s internal price reference could be updated mid-transaction with insufficient restrictions — a $280M flash loan temporarily inflated pool balances, and the system recorded the distorted valuation as real. The original attacker deployed the exploit contract but never profited — a MEV bot decompiled it one block later and captured the entire $4.13M.

Makina Finance used a lastTotalAum value as its price anchor for DUSD share pricing. Any user could refresh this value mid-transaction by calling updateTotalAum(), and the function consumed current pool balances as input — no time delay, no TWAP, no access control. A permissionless AUM update and spot-price trust in the same transaction made atomic manipulation possible — a textbook case of integration risk and threat-model gaps surviving multiple audits.

The attacker flash-loaned 280M USDC and used it to inflate balances across Curve pools. They then called accountForPosition() and updateTotalAum() to bake the manipulated state into the protocol's accounting. A rate-based change guard existed but was bypassed by spreading the inflation across four sequential update pairs per run, each staying within the per-second change budget.

The attacker’s original transaction was front-run by a MEV bot in the very next block, capturing the entire profit.

Recovery update: X post.

Exploit execution sequence (as replicated by the MEV bot):

1. Flash-loaned 280M USDC.
2. Deposited 100M USDC into the DUSD/USDC Curve pool and exchanged 10M to DUSD; added 170M USDC to the Curve 3pool.
3. Routed the inflated 3CRV into the MIM/3CRV pool to skew calc_withdraw_one_coin output upward.
4. Called accountForPosition() on CALIBER with Weiroll commands that read the inflated spot price, storing an inflated pos.value.
5. Called updateTotalAum() on MACHINE — internally called getDetailedAum() on CALIBER and persisted the inflated AUM as _lastTotalAum. Repeated in four incremental steps to stay under the rate guard.
6. Swapped all DUSD back to USDC via the now-overpriced pool and removed LP, capturing a ~5.1M USDC surplus from the DUSD/USDC pool.
7. Unwound MIM positions, repaid both flash loans, and swapped proceeds to 1,299 WETH via Uniswap V3.
8. Ran the full sequence twice.

Takeaway: When a price anchor can be written and read in the same transaction by any caller, flash loan manipulation becomes trivial. Access control and time delays on state-updating functions aren’t optional — they’re the difference between a price feed and a payout surface.

4. Solv Protocol — Callback Double-Mint — $2.73M

Date: March 5, 2026
Chain: Ethereum
Attack vector: ERC-3525 transfer callback triggered a mint before the calling function minted again

TLDR: The vault’s deposit function minted tokens twice per call. This was the default behavior, not a hidden exploit path. The attacker compounded it 22 times in one transaction: 135 became 567 million BRO tokens before cashing out.

Solv Protocol’s BitcoinReserveOffering vault accepted ERC-3525 semi-fungible tokens as collateral and minted BRO in return. The mint() function called doSafeTransferIn to pull the depositor's token into the contract. That transfer triggered the onERC3525Received callback, which computed the output value and called _mint(). Execution then returned to mint(), which recomputed the same value and called _mint() again.

One deposit, two mints. This wasn’t a special code path — it was the default behavior. Any user who ever called mint() legitimately would have received double tokens. The execution-order bug made this a clean case for check-effects-interactions and callback hardening — but what made it devastating was the compounding: the attacker repeated the cycle 22 times in a single transaction, amplifying 135 BRO to 567 million before converting to ETH.

An attempted deposit to RailGun was rejected by AML filters; funds were then deposited into Tornado Cash.

Full post-mortem: X post.

Attacker execution sequence:

1. Acquired 135 BRO, burned them through the reserve to receive a GOEFS SFT worth the equivalent value.
2. Called mint() on BitcoinReserveOffering from their EOA, depositing the GOEFS SFT.
3. Inside mint(), doSafeTransferIn triggered an ERC-3525 safe transfer of the GOEFS SFT into the contract.
4. The GOEFS contract called supportsInterface on BitcoinReserveOffering — receiving true — then called onERC3525Received back on BitcoinReserveOffering itself, mid-execution of mint(). Inside that callback, _mint() fired — first mint.
5. Execution returned to mint(), which called _mint(msg.sender, value) a second time — same amount, doubled output.
6. Burned the doubled BRO for a proportionally larger GOEFS SFT and repeated the two-mint cycle 22 times, compounding 2x each round: 135 → 270 → 541 → … → 567M BRO total.
7. Swapped 165M of the accumulated BRO for SolvBTC at the BRO-SolvBTC exchange.
8. Converted 38.0474 SolvBTC via Uniswap V3 to ETH, attempted RailGun (rejected by AML filters), then deposited into Tornado Cash.

Takeaway: Check-effects-interactions isn’t just about reentrancy from external contracts. Callback flows in standard token interfaces (ERC-721, ERC-1155, ERC-3525) create execution-order risks in the receiving contract itself. If your mint logic calls a safe transfer that calls back into your own contract, you’ve created a self-reentrancy path.

5. Resolv — Compromised Key + Missing Validation — ~$25M

Date: March 22, 2026
Chain: Ethereum
Attack vector: Compromised SERVICE_ROLE key called completeSwap with arbitrary mint amounts; contract had no on-chain bounds

TLDR: The contract let a privileged off-chain key decide how many tokens to mint, with no cap or sanity check. The attacker compromised that key, used it through the normal process, and turned $300K in deposits into 80 million unbacked tokens — extracting ~$25M before the protocol paused.

Resolv’s USR stablecoin minting used a two-step flow: users called requestSwap to deposit USDC, then an off-chain service with a privileged SERVICE_ROLE key called completeSwap to finalize how much USR to mint.

The contract recorded the deposited amount but accepted _targetAmount entirely from the SERVICE_ROLE caller. The only on-chain bound was transferableAmount >= minExpectedAmount — and all three attacker requests set minExpectedAmount to 0.

The attacker didn’t bypass access control. They used the compromised SERVICE_ROLE key through the intended backend path, and the contract treated the input as truth. Three requests totaling 300,000 USDC produced 80,019,895 USR after fees. The attacker dumped the unbacked USR into available liquidity and extracted roughly $25M before the protocol paused.

Attacker execution sequence:

1. Called requestSwap three times from 0x04a2...caed, each time depositing 100,000 USDC and setting minExpectedAmount to 0.
2. Used the compromised SERVICE_ROLE EOA 0x15ca...6398 to call completeSwap for request 30 with _targetAmount = 50,000,000e18.
3. Called completeSwap again for request 32 with _targetAmount = 99,995.213000000012278e18.
4. Called completeSwap a third time for request 33 with _targetAmount = 30,000,000e18.
5. Received 49,950,000, 99,895.217787, and 29,970,000 USR after fees, for 80,019,895.217787 USR total.
6. Dumped the illicitly minted USR into available liquidity and extracted about $25M before the protocol paused.

Takeaway: When minting logic trusts an off-chain key to set arbitrary output amounts with no on-chain ratio check, the key becomes the entire security model. A compromised key isn’t an edge case — it’s the primary threat. On-chain invariants (max mint ratios, collateral checks, rate limits) exist precisely because off-chain components fail.

Consensys Diligence has been auditing Ethereum smart contracts since 2017. For more on our security research and tooling, visit consensys.io/diligence.