Back to Blog

~$135萬美元損失:BarnBridge、DeFiTuna | BlockSec 週報

Code Auditing
July 22, 2026
10 min read
Key Insights

在過去一週(2026/07/13 - 2026/07/19),以下 2 起值得關注的安全事件被列為重點,涉及以太坊和 Solana 上約 135 萬美元的總損失。

日期 事件 類型 預估損失
2026/07/15 BarnBridge 治理機制不當 ~$776K
2026/07/16 DeFiTuna 健康檢查缺陷 ~$570K
  • DeFiTuna:倉位健康檢查在資產價值為零但債務不為零的情況下,將其判定為健康;攻擊者利用可控的交換路由及另一個低流動性池來觸發此缺陷,並建立壞帳倉位。
  • BarnBridge:一個已棄用的治理系統遭到利用,攻擊者藉此修改關鍵協議配置並提取用戶已授權的資金。

Web3 最佳安全審計機構

在上線前驗證設計、程式碼與業務邏輯

本週重點:DeFiTuna

根本原因是倉位健康檢查中存在一個有缺陷的零值分支:資產價值為零且尚有約 57 萬美元未償債務的倉位,卻被判定為健康。攻擊者透過將交換路由導向另一個低流動性池來觸發此缺陷,但健康檢查本應是攔截由此產生壞帳的控制機制。

2026 年 7 月 16 日,Solana 上支援槓桿現貨倉位的借貸協議 DeFiTuna 遭到攻擊,損失約 57 萬美元的 USDC [1]。根本原因是倉位健康檢查中存在一個有缺陷的零值分支,即便資產價值為零且債務不為零,該分支仍將倉位接受為健康狀態。攻擊者以零抵押品開設槓桿倉位,從協議金庫借入 USDC,並將交換路由導向攻擊者控制的低流動性池,導致倉位僅收到極少量的目標代幣。精度截斷進而將倉位價值四捨五入為零,健康檢查將該倉位接受為健康,從而產生約 57 萬美元的壞帳。

背景

DeFiTuna 是 Solana 上一個支援保證金交易的借貸協議。用戶可以透過提供一種代幣作為抵押品、從協議金庫借款,並將借入的資金兌換為目標代幣來開設現貨倉位。隨後,系統會對照債務檢查所產生的倉位,以判斷其是否健康。

在 DeFiTuna 現貨市場中,兩種池子代幣分別被稱為代幣 A 和代幣 B。在受攻擊的市場中,代幣 A 為 TUNA,代幣 B 為 USDC

  • USDC 為抵押代幣(collateral_token)。用戶存入 USDC 作為保證金,從 DeFiTuna 的金庫借入額外的 USDC,借入的 USDC 隨後被兌換為 TUNA
  • TUNA 為倉位代幣(position_token),即兌換後倉位所持有的資產。其淨效果是以 USDC 債務為資金來源,對 TUNA 進行槓桿做多。
  • 金庫帳戶持有出借方的流動性,是借入資金的來源。
  • AMM 池為 TUNA/USDC 交易對提供市場流動性和價格參考。

DeFiTuna 透過 Jupiter(Solana 上的交換聚合器)路由倉位兌換。兌換路徑作為 Jupiter 路由資料和路由帳戶提供給 DeFiTuna 指令。由於呼叫方提供這些帳戶,呼叫方可以控制兌換所使用的池子。在執行兌換之前,DeFiTuna 會透過比較正常市場池價格與預言機價格,執行兌換前的價格檢查。

漏洞分析

存在缺陷的程式是 DeFiTuna(tuna4u...nogD)。

根本原因是倉位健康檢查中存在一個有缺陷的零值分支。兌換後,DeFiTuna 透過將持有的 TUNA 換算為 USDC 來對倉位進行估值。如果 TUNA 餘額小到足以向下取整為零,total 欄位便會變為 0。健康檢查邏輯將 total == 0 視為健康狀態,而不要求 debt == 0

攻擊分析

兩個設計特性使攻擊者得以控制借入資金的路由方向。第一,DeFiTuna 接受呼叫方提供的 Jupiter RouteV2 資料,而未根據預言機價格和借入金額自行推導最低可接受的 TUNA 輸出量。第二,兌換前的預言機檢查僅驗證正常的 DeFiTuna 市場池,而非 Jupiter 路由實際使用的池子。

注意: 項目方認可的事後分析 [1] 描述攻擊者創建的池子初始化價格接近合法預言機價格。鏈上證據顯示,該池子以極端價格初始化;兌換前檢查之所以通過,是因為它驗證的是獨立的正常市場池,而非攻擊者控制的池子。

以下分析基於交易 4x33Dq...EXj1。攻擊者執行了多筆攻擊交易,此筆交易闡明了核心技術手法。

  • 步驟 1:攻擊者創建了一個新的 Fusion TUNA/USDC 池。該池使用真實的 TUNAUSDC 鑄幣地址,但與正常的 DeFiTuna 市場池相互獨立。該池以接近刻度 208636 的極端價格初始化,將 TUNA 定價為每個 TUNA 約 11.49 億 USDC。在此價格下,即使極少量的 TUNA 也能在一次兌換中吸收數十萬美元的 USDC
  • 步驟 2:攻擊者在新池中設置了兩個小額賣方限價單。每筆訂單存入 0.000526 TUNA,合計 0.001052 TUNA。由於池子價格極高,這少量的 TUNA 供應在兌換執行時,足以吸收全部借入的 USDC 金額。
  • 步驟 3:池子準備就緒後,攻擊者以 TUNA 為倉位代幣、USDC 為抵押代幣,開設了一個 DeFiTuna 現貨倉位。攻擊者提供 0 USDC 作為抵押品,並從 DeFiTuna 的 USDC 金庫借入 570,000 USDC
  • 步驟 4:兌換前,DeFiTuna 將正常市場池價格與預言機價格進行比較。正常池的即時價格接近預言機價格,因此檢查通過。此項檢查僅驗證正常的 DeFiTuna 市場池,並未驗證 Jupiter 路由所使用的 Fusion 池。
  • 步驟 5:兌換按照攻擊者提供的 Jupiter 路由執行,將資金導向攻擊者控制的 Fusion 池,最低輸出量實際上被設為零。扣除協議費用後,569,601 USDC 被路由至攻擊池,而 DeFiTuna 倉位僅收到 494TUNA 原始單位(0.000494 TUNA)。
  • 步驟 6:兌換後,該倉位持有約 570,000 USDC 的債務,以及僅有塵埃量的 TUNA。當 DeFiTuna 將該 TUNA 餘額換算為 USDC 價值時,結果向下取整為 0。健康檢查將 total == 0 視為健康狀態,因此該壞帳倉位被接受。
  • 步驟 7:攻擊者提取了累積在攻擊者控制的 Fusion 池中的 USDC。兩筆提款金額幾乎相等,與步驟 2 中創建的兩個限價單倉位相對應。

結論

根本原因是健康檢查的 total == 0 分支無論未償債務為何,均接受倉位為健康狀態。攻擊者控制的路由和流動性創造了觸發此缺陷的條件,但健康檢查才是本應阻止壞帳產生的最終控制機制。

最直接的修復方案是拒絕任何 total == 0debt > 0 的倉位。一個資產價值為零但仍有未償債務的倉位,絕不可能是健康的。此外,協議應根據預言機價格和借入金額,獨立於呼叫方提供的路由參數,推導出最低可接受的兌換輸出量。將預言機/價格檢查綁定到實際使用的兌換池,或根據協議計算的下限驗證兌換輸出,可以防止兌換前檢查被繞過,從而避免透過未經驗證的池子進行路由的情況發生。

參考資料

開始使用 Phalcon Explorer

深入分析交易,做出明智決策

立即免費試用

本週更多事件

BarnBridge

2026 年 7 月 15 日,以太坊上的收益分配協議 BarnBridge 遭到攻擊,損失約 77.6 萬美元的 USDC [1]。根本原因是已廢棄的治理合約仍保留修改關鍵協議配置的權限。攻擊者獲取了足夠的投票權以通過惡意提案,將協議組件的控制器替換為攻擊者自己的合約,隨後利用新控制器轉移了用戶已授權的 USDC

背景

BarnBridge 是一個由 DAO 治理的協議,將用戶資金分配至不同的借貸市場以產生收益。投票權由質押的 BOND 數量和鎖倉期限決定。提交提案需要至少佔總投票權 1% 的投票力。提案須達到最低 40% 的法定人數,並獲得至少 60% 的參與票數支持才能通過。提案提交後,須經過兩天的預熱期、三天的投票期和兩天的排隊期,方可執行。

漏洞分析

根本原因是已廢棄的治理合約在協議被棄用後,仍保留修改關鍵協議配置的權限。治理系統控制著 CompoundProviderController 分配,而 CompoundProvider 是一個用戶此前已授權使用其 USDC 的合約。由於 BarnBridge 已被棄用,質押的 BOND 總量和活躍參與度大幅下降,使得惡意提案的通過變得極為容易。

攻擊分析

以下分析基於交易 0xd191fe...895afb

攻擊者花費約 0.335 ETH 購入約 32,795 枚 BOND,隨後存入並鎖定 32,000 枚 BOND,獲得約 43% 的總投票權。

  • 步驟 1:攻擊者部署了一個代理合約並提交了一個惡意提案。兩天預熱期結束後,攻擊者投入全部投票權表示支持,同時滿足了法定人數和批准要求。
  • 步驟 2:攻擊者將提案加入執行佇列。兩天排隊期結束後,攻擊者執行該提案,將 CompoundProviderController 設置為攻擊者的代理合約。
  • 步驟 3:攻擊者升級了代理合約的邏輯,並呼叫 _takeUnderlying(),利用約 50 名用戶的未到期 USDC 授權額度,將其 USDC 轉移至 CompoundProvider。攻擊者隨後呼叫 transferFees() 將資金轉至攻擊者地址,獲利約 77.6 萬美元的 USDC

結論

若一個 DAO 或協議正在被棄用,其治理合約應放棄或永久禁用修改安全關鍵配置的能力,尤其是管理員、控制器和資金提取權限。具體措施包括:撤銷治理合約對下游合約的管理員角色、將所有權轉移至銷毀地址,或執行最終提案以禁用升級功能並將控制器引用設置為不可變的安全值。在已廢棄的協議上保留治理權限,會製造低成本攻擊面:隨著參與度下降,達到法定人數所需的資本也會等比例降低。

參考資料

Sign up for the latest updates

Best Security Auditor for Web3

Validate design, code, and business logic before launch. Aligned with the highest industry security standards.

BlockSec Audit