~$1.35M Lost: BarnBridge, DeFiTuna

During the past week (2026/07/13 - 2026/07/19), the following 2 notable security incidents are featured, involving approximately $1.35M in total losses on Ethereum and Solana.

Date	Incident	Type	Estimated Loss
2026/07/15	BarnBridge	Improper Governance	~$776K
2026/07/16	DeFiTuna	Flawed Health Check	~$570K

DeFiTuna: The position health check accepted zero asset value as healthy with non-zero debt; the attacker used controlled swap routing and a separate low-liquidity pool to trigger this defect and create a bad debt position.
BarnBridge: A deprecated governance system was exploited to modify critical protocol configuration and drain user-approved funds.

Weekly Highlight: DeFiTuna

The root cause was a flawed zero-value branch in the position health check: a position with zero asset value and ~$570K of outstanding debt was accepted as healthy. The attacker triggered this defect by routing the swap through a separate low-liquidity pool, but the health check was the control that should have caught the resulting bad debt.

On July 16, 2026, DeFiTuna, a lending protocol on Solana that supports leveraged spot positions, was exploited for approximately $570K in USDC [1]. The root cause was a flawed zero-value branch in the position health check that accepted a position as healthy even when its asset value was zero and its debt was non-zero. The attacker opened a leveraged position with zero collateral, borrowed USDC from the protocol vault, and routed the swap through an attacker-controlled low-liquidity pool, causing the position to receive a negligible amount of the target token. Precision truncation then rounded the position value to zero, and the health check accepted the position as healthy, creating approximately $570K of bad debt.

Background

DeFiTuna is a lending protocol on Solana that supports margin trading. A user can open a spot position by supplying one token as collateral, borrowing from a protocol vault, and swapping the borrowed funds into a target token. The resulting position is then checked against the debt to determine whether it is healthy.

In a DeFiTuna spot market, the two pool tokens are referred to as token A and token B. In the attacked market, token A was TUNA and token B was USDC.

USDC was the collateral token (collateral_token). The user deposits USDC as margin, borrows additional USDC from DeFiTuna's vault, and the borrowed USDC is then swapped into TUNA.
TUNA was the position token (position_token), the asset the position holds after the swap. The net effect is a leveraged long on TUNA funded by USDC debt.
The vault accounts hold lender liquidity and are the source of borrowed funds.
The AMM pool supplies market liquidity and price context for the TUNA/USDC pair.

DeFiTuna routes position swaps through Jupiter, a Solana swap aggregator. The swap path is provided to the DeFiTuna instruction as Jupiter route data and route accounts. Because the caller supplies these accounts, the caller controls which pool the swap uses. Before executing the swap, DeFiTuna performs a pre-swap price check by comparing the normal market pool price against an oracle.

Vulnerability Analysis

The buggy program is DeFiTuna (tuna4u...nogD).

The root cause was a flawed zero-value branch in the position health check. After a swap, DeFiTuna valued the position by converting the held TUNA into USDC terms. If the TUNA balance was small enough to round down to zero, the total field became 0. The health check logic treated total == 0 as a healthy state without requiring debt == 0.

Attack Analysis

Two design properties gave the attacker control over where the borrowed funds were routed. First, DeFiTuna accepted caller-supplied Jupiter RouteV2 data without deriving its own minimum acceptable TUNA output from the oracle price and borrowed amount. Second, the pre-swap oracle check only validated the normal DeFiTuna market pool, not the pool that the Jupiter route would actually use.

Note: The post-incident analysis endorsed by the project team [1] describes the attacker-created pool as initialized near the legitimate oracle price. On-chain evidence shows the pool was initialized at an extreme price; the pre-swap check passed because it validated the separate normal market pool, not the attacker-controlled pool.

The following analysis is based on the transaction 4x33Dq...EXj1. Multiple attack transactions were executed; this one illustrates the core technique.

Step 1: The attacker created a new Fusion TUNA/USDC pool. This pool used the real TUNA and USDC mints but was separate from the normal DeFiTuna market pool. The pool was initialized at an extreme price near tick 208636, pricing TUNA at roughly 1.149 billion USDC per TUNA. At this price, even a tiny amount of TUNA could absorb hundreds of thousands of USDC in a swap.

Step 2: The attacker placed two small sell-side limit orders in the new pool. Each order deposited 0.000526 TUNA, totaling 0.001052 TUNA. Because the pool price was extremely high, this tiny TUNA supply could absorb the entire borrowed USDC amount when the swap executed.

Step 3: With the pool prepared, the attacker opened a DeFiTuna spot position with TUNA as the position token and USDC as the collateral token. The attacker supplied 0 USDC as collateral and borrowed 570,000 USDC from DeFiTuna's USDC vault.

Step 4: Before the swap, DeFiTuna compared the normal market pool price with the oracle price. The normal pool's spot price was close to the oracle, so the check passed. This check only validated the normal DeFiTuna market pool; it did not validate the Fusion pool that the Jupiter route would use.

Step 5: The swap followed the attacker-supplied Jupiter route, which directed the funds through the attacker-controlled Fusion pool with the minimum output effectively set to zero. After the protocol fee, 569,601 USDC was routed into the attack pool, while the DeFiTuna position received only 494 raw units of TUNA (0.000494 TUNA).

Step 6: After the swap, the position held approximately 570,000 USDC of debt and only a dust amount of TUNA. When DeFiTuna converted that TUNA balance into USDC value, the result rounded down to 0. The health check treated total == 0 as healthy, so the bad debt position was accepted.

Step 7: The attacker withdrew the USDC accumulated in the attacker-controlled Fusion pool. The two withdrawals were nearly equal, matching the two limit-order positions created in Step 2.

Conclusion

The root cause was the health check's total == 0 branch accepting a position as healthy regardless of outstanding debt. Attacker-controlled routing and liquidity created the conditions to trigger this defect, but the health check was the final control that should have prevented the bad debt.

The most direct fix is to reject any position where total == 0 and debt > 0. A zero-value position with outstanding debt is never healthy. Additionally, the protocol should derive a minimum acceptable swap output from the oracle price and borrowed amount, independent of the caller-supplied route parameters. Binding the oracle/price check to the actual swap pool, or verifying the swap output against a protocol-computed floor, would prevent the pre-swap check from being bypassed by routing through an unvalidated pool.

References

[1] DeFiTuna Post-Incident Statement

More Incidents This Week

BarnBridge

On July 15, 2026, BarnBridge, a yield-allocation protocol on Ethereum, was exploited for approximately $776K in USDC [1]. The root cause was the abandoned governance contract retaining authority to modify critical protocol configuration. The attacker acquired sufficient voting power to pass a malicious proposal that replaced the controller of a protocol component, then used the new controller to transfer user-approved USDC.

Background

BarnBridge is a DAO-governed protocol that allocates users' funds across different lending markets to generate yield. Voting power is determined by the amount of BOND staked and the lock-up duration. Creating a proposal requires voting power equal to at least 1% of the total voting power. A proposal must meet a minimum quorum of 40% and receive at least 60% of the total participating votes in favor to pass. Once submitted, a proposal goes through a two-day warm-up period, a three-day voting period, and a two-day queue period before it can be executed.

Vulnerability Analysis

The root cause was the abandoned governance contract retaining the authority to modify critical protocol configuration after the protocol had been deprecated. The governance system controlled the Controller assignment for CompoundProvider, a contract that users had previously approved to spend their USDC. Because BarnBridge had been deprecated, total staked BOND and active participation had dropped significantly, making hostile proposal passage trivially achievable.

Attack Analysis

The following analysis is based on the transaction 0xd191fe...895afb.

The attacker spent approximately 0.335 ETH to acquire about 32,795 BOND, then deposited and locked 32,000 BOND, obtaining approximately 43% of the total voting power.

Step 1: The attacker deployed a proxy contract and submitted a malicious proposal. After the two-day warm-up period, the attacker cast all of their voting power in favor, satisfying both the quorum and approval requirements.

Step 2: The attacker queued the proposal. After the two-day queue period elapsed, the attacker executed it, setting the Controller of CompoundProvider to the attacker's proxy contract.

Step 3: The attacker upgraded the proxy contract's logic and called _takeUnderlying(), which used the outstanding USDC allowances of approximately 50 users to transfer their USDC into CompoundProvider. The attacker then called transferFees() to forward the funds to the attacker's address, profiting approximately $776K in USDC.

Conclusion

If a DAO or protocol is being deprecated, its governance contract should relinquish or permanently disable the ability to modify security-critical configurations, especially administrator, controller, and fund-withdrawal permissions. Concrete measures include revoking the governance contract's admin role over downstream contracts, transferring ownership to a burn address, or executing a final proposal that disables upgrade functions and sets controller references to immutable safe values. Leaving governance authority intact on a deprecated protocol creates a low-cost attack surface: as participation declines, the capital required to reach quorum drops proportionally.

References

[1] Phalcon Alert: BarnBridge Exploit

About BlockSec

BlockSec is a full-stack blockchain security and crypto compliance provider. We build products and services that help customers to perform code audit (including smart contracts, blockchain and wallets), intercept attacks in real time, analyze incidents, trace illicit funds, and meet AML/CFT obligations, across the full lifecycle of protocols and platforms.

BlockSec has published multiple blockchain security papers in prestigious conferences, reported several zero-day attacks of DeFi applications, blocked multiple hacks to rescue more than 20 million dollars, and secured billions of cryptocurrencies.