Web3 每週安全事件速報 | 2026 年 2 月 2 日 - 2 月 8 日

在過去的一週（2026 年 2 月 2 日至 2 月 8 日），BlockSec 偵測並分析了六起攻擊事件，合計預估損失約 380 萬美元。下表總結了這些事件，隨後的章節提供了每個案例的詳細分析。

1. CrossCurve 事件

簡要總結

2026 年 2 月 2 日，CrossCurve 協議遭到攻擊，導致約 280 萬美元的損失。根本原因是 ReceiverAxelar 合約公開了一個無權限控制的 expressExecute() 函數，該函數繞過了標準的 Axelar Gateway 驗證流程。接收方僅根據外部提供的數據進行對等地址檢查。因此，攻擊者構造了一次惡意跨鏈呼叫以觸發銷毀與解鎖機制，非法釋放了 999,787,453e18 枚 EYWA 代幣給攻擊者。

背景

CrossCurve 是由 Eywa.Fi 開發的跨鏈橋協議，建立在 Axelar 跨鏈訊息傳遞框架之上。

在 Axelar 預期的安全模型中，跨鏈訊息由 Axelar Gateway 轉發，並且必須在目標鏈上通過 validateContractCall() 進行明確驗證。只有經過 Gateway 加密批准的訊息才能進入執行階段。

為了降低延遲，Axelar 還提供了一種快速執行機制，即接收方合約可以在 Gateway 完成驗證之前樂觀地執行訊息。此設計要求嚴格的存取控制，以確保只有受信任的執行者可以呼叫快速執行路徑；否則，未經驗證的跨鏈訊息可能會被過早處理。

漏洞分析

根本原因在於 ReceiverAxelar 公開了一個無需權限的 expressExecute() 函數，該函數無需 Axelar Gateway 授權即可直接到達特權 _execute() 路徑。

在 Axelar 正確的安全模型中，跨鏈訊息必須首先通過基於證明的執行獲得 Gateway 的批准，然後通過 validateContractCall() 在目標鏈上進行驗證，該驗證將 (commandId, sourceChain, sourceAddress, contractAddress, payloadHash) 綁定到單次授權執行。

然而，expressExecute() 路徑完全跳過了此驗證。它僅依賴於使用 sourceChain 和 sourceAddress 進行的對等檢查，而這兩者皆由攻擊者控制，因此無法提供真正的安全性。這使得攻擊者能夠提供欺騙性訊息，強制執行 receiveData 分支，並執行任意負載，最終觸發了 Eywa CLP Portal 上的 unlock()，導致跨鏈資產的非法釋放。

攻擊分析

• 步驟 1：攻擊者直接呼叫 expressExecute()，偽造了 sourceChain、sourceAddress 和 payload。由於 expressExecute() 跳過了 Gateway 驗證並直接進行到 _execute()，唯一的安全措施是白名單對等地址檢查：require(peers[sourceChain] == sourceAddress.toAddress())。由於 sourceChain 和 sourceAddress 均為外部匯入，此檢查無效。攻擊者通過提供正確的白名單對等地址，成功繞過了此限制。

• 步驟 2：偽造的 payload 被轉發到 Receiver.receiveData() 分支。resume() 函數基於惡意負載執行了跨鏈操作 PortalV2.unlock()，導致資金未經授權解鎖給攻擊者。

結論

該事件從根本上是由於跨鏈接收合約中加速執行路徑上的存取控制不足所導致。通過將 expressExecute() 公開為無需權限的函數，並僅依賴外部提供的對等資訊，CrossCurve 有效地允許攻擊者繞過 Axelar Gateway 的安全保證並執行任意跨鏈負載。

為了在未來減輕類似風險，整合加速或樂觀執行機制的跨鏈協議應：

• 對快速路徑執行函數強制執行嚴格的呼叫者驗證，確保只有受信任的轉發器或閘道才能呼叫它們。

• 避免依賴由攻擊者控制的元資料（如源鏈或地址）作為授權的唯一基礎。

• 將快速執行視為特權操作，並應用與標準驗證執行路徑同等的深度防禦檢查。

在設計跨鏈系統時，嚴格遵守這些原則至關重要，因為單一驗證繞過可能導致多個網路上的系統性資產損失。

2. GYD 事件

簡要總結

2026 年 2 月 3 日，GYD 協議遭到攻擊，導致約 70 萬美元的損失。根本原因是其 CCIP 接收方將攻擊者控制的訊息數據作為執行上下文。攻擊是由一條從 Arbitrum 發送的 CCIP 訊息觸發的，該訊息在訊息層通過了正確的驗證，但其解碼後的負載隨後被用於在 _ccipReceive() 中執行任意外部呼叫。通過將解碼後的接收者設為 GYD 代幣合約並提供 approve(attacker, type(uint256).max) 的 calldata，託管合約無意中授權了攻擊者對其 GYD 餘額的無限使用權限。攻擊者隨後通過 transferFrom() 耗盡了資金。

背景

GydL1CCipEscrow 合約是一個基於 Chainlink CCIP 標準的跨鏈資產託管合約。用戶將 GYD 代幣鎖定在 L1 的此合約中，該合約隨後通過 CCIP 發送跨鏈訊息至目標鏈。反之，當跨鏈訊息到達託管合約時，CCIP 會驗證其真實性並觸發 _ccipReceive()。該函數解析傳入的 calldata 以提取 tx.recipient 和 data，基於解析出的參數（金額和接收者）執行 GYD 轉帳或解鎖邏輯；如果 data 不為空，則會通過 recipient.functionCall(data) 執行任意外部呼叫。

漏洞分析

核心漏洞在於 GydL1CCipEscrow 未對從跨鏈訊息中解碼出的 tx.recipient 地址進行驗證。攻擊者可以將 tx.recipient 設為 GYD 代幣合約地址，並將 data 構建為 approve(attacker, type(uint256).max)。由於託管合約持有大量鎖定的 GYD 代幣，這種不受限制的外部呼叫導致託管合約將 GYD 代幣的完全授權授予了攻擊者，然後攻擊者便能通過 transferFrom() 耗盡所有資金。

攻擊分析

• 步驟 1：攻擊者在 Arbitrum 上發起一筆惡意 CCIP 訊息，指定 tx.recipient 為以太坊上的 GYD 代幣合約地址，並將 tx.data 指定為 approve(attacker, type(uint256).max) 的編碼 calldata。

• 步驟 2：當該訊息在以太坊上處理時，GydL1CCipEscrow 合約的 _ccipReceive() 函數在未驗證 tx.recipient 的情況下，在 GYD 代幣合約上執行了批准操作。隨後攻擊者在 GYD 代幣上呼叫 transferFrom() 以耗盡所有託管資金。

結論

此事件的根本原因在於 GydL1CCipEscrow 合約在處理跨鏈訊息時，未能驗證解碼後的負載，從而允許攻擊者構造惡意的跨鏈呼叫。對於跨鏈橋通訊，開發者應：

• 禁止託管合約直接呼叫代幣合約：確保跨鏈訊息負載無法觸發對託管代幣合約的呼叫。

• 實作執行目標白名單：將 tx.recipient（或 tx.target）限制在一組定義明確的受信任地址中。

3. SOFI Token 事件

簡要總結

2026 年 2 月 5 日，BNB Chain 上的 SOFI 代幣遭到攻擊，導致約 2.96 萬美元的損失。

根本原因是代幣重寫的 _transfer() 函數中實作了有缺陷的銷毀機制。通過濫用從 PancakeSwap 流動性池中直接移除代幣並觸發隨後 sync() 的延遲銷毀邏輯，攻擊者能夠人為抬高 SOFI 價格。通過重複的轉帳和交換操作，攻擊者從池中提取了過剩的 USDT 流動性，並在償還閃電貸後獲利。

背景

SOFI 是一個部署在 BNB Chain 上的自定義 ERC-20 代幣。與標準 ERC-20 實作不同，SOFI 代幣重寫了內部的 _transfer() 函數，嵌入了與賣出操作期間銷毀代幣相關的額外邏輯。

該代幣在 PancakeSwap 風格的恆定乘積 AMM 池（SOFI–USDT）中進行交易。在此類池中，代幣價格源於代幣儲備的比例。任何對池餘額的意外變動（尤其是非交換操作引起的）都可能直接操縱價格。

在此設計中，代幣合約本身會在轉帳期間與流動性池互動，這使得池的儲備會計依賴於代幣端的邏輯，而非純粹的 AMM 機制。

漏洞分析

漏洞在於 SOFI 的銷毀機制與 _transfer() 內的池互動。

當 SOFI 代幣轉移到流動性池地址時，合約將該轉帳解讀為賣出，並增加內部累加變數 waitBurnTokenAmount。然而，累加金額不會立即銷毀。相反，它是在隨後轉移到池中時，從池的餘額中扣除並銷毀，隨後呼叫池的 sync() 函數。

這種設計引入了兩個關鍵問題：

1. 直接操縱池餘額 直接從池中銷毀代幣減少了 SOFI 儲備而沒有相應的 USDT 流出，違反了 AMM 不變量，並人為提高了 SOFI 價格。

2. 延遲且可由攻擊者控制的執行 由於銷毀僅在未來轉帳時發生，攻擊者可以精確控制銷毀和 sync() 發生的時間，這使他們能夠 positioning 自己以從價格失真中獲利。

結果，池價格不再反映真實的供需動態，從而實現了可提取的套利。

攻擊分析

• 步驟 1：通過閃電貸借入 USDT。

• 步驟 2：在 SOFI–USDT 池中將 USDT 交換為 SOFI。

• 步驟 3：將 SOFI 轉入池中並呼叫 skim() 以最小損失增加 waitBurnTokenAmount。

• 步驟 4：再次將 SOFI 轉入池中以觸發銷毀 + sync()，推高 SOFI 價格，然後將 SOFI 交換為 USDT。

• 步驟 5：重複步驟 4。新累加的 waitBurnTokenAmount 僅在下一次轉帳時銷毀，因此需要多次迭代。

• 步驟 6：從池中耗盡 USDT，然後償還閃電貸。

結論

此事件最終是由於不安全的代幣側銷毀機制直接操縱了 AMM 池餘額所致。通過將延遲銷毀邏輯嵌入 _transfer() 並從流動性池本身執行銷毀，SOFI 代幣打破了恆定乘積 AMM 的基本假設，並實現了確定性的價格操縱。

對於重寫 _transfer() 的 ERC-20 代幣，開發者應特別注意避免：

• 直接從流動性池中銷毀代幣

• 引入影響池儲備的延遲或有狀態機制

• 將代幣邏輯與 AMM 內部運作過度耦合

總體而言，代幣經濟學相關的邏輯絕不應被允許任意更改池餘額，因為即使是微小的偏差也可能被反覆利用來耗盡流動性。

4. 未知質押協議事件 (2026 年 2 月 5 日)

簡要總結

2026 年 2 月 5 日，以太坊上的未知質押協議遭到攻擊，導致約 7.16 萬美元的損失。

根本原因是協議在提款時依賴於未經驗證、由用戶提供的輸入數據。具體來說，協議在沒有驗證的情況下將攻擊者控制的 routerCalldata 和 LP 金額轉發給 Pendle Router。通過構造移除協議全部 LP 部位的 calldata 並將自己設定為接收者，攻擊者得以耗盡金庫持有的所有資產。

背景

未知質押協議是一個建立在 Pendle Finance 之上的簡單收益金庫。用戶將資產存入金庫，該金庫隨後通過 Pendle Router 路由這些資產以鑄造收益累積部位。在內部，存款會轉換為 SY，分割為 PT 和 YT，並合併形成 Pendle LP 代幣。

協議託管所有 LP 代幣並維護每個用戶存入的基礎資產賬目。當用戶提款時，金庫通過 Pendle Router 贖回 LP 代幣並將相應資產返還給用戶。

漏洞分析

根本原因是輸入數據未經驗證。函數 withdrawWithCalldataMultiToken() 接收四個參數：底層代幣、底層金額、LP 金額和 routerCalldata。它僅檢查用戶記錄的底層餘額是否足夠，但未驗證 LP 金額或 routerCalldata 的內容。當通過 Pendle Router 移除流動性時，合約完全依賴於 routerCalldata 中嵌入的參數。結果，攻擊者可以傳入協議的全部 LP 餘額並將自己設定為接收者，從而耗盡金庫持有的所有資產。

攻擊分析

• 步驟 1：採取 USDC 閃電貸。

• 步驟 2：存入少量 USDC 到協議中，該協議通過 Pendle Router 路由資金以添加流動性並鑄造 LP。

• 步驟 3：呼叫 withdrawWithCalldataMultiToken()，並使用精心構造的 routerCalldata，將 receiver 設定為攻擊者，並將 lpAmount 設定為協議的全部 LP 餘額。

• 步驟 4：協議使用攻擊者控制的參數通過 Pendle Router 移除流動性，並將所有資產發送給攻擊者。

• 步驟 5：將收到的資產換回 USDC，償還閃電貸，保留剩餘部分作為利潤。

結論

此事件最終是由於在關鍵提款路徑中盲目信任由攻擊者控制的外部輸入所導致。通過將任意 calldata 和 LP 金額轉發給外部路由器而未經驗證，該協議允許用戶執行遠超其應得份額的提款，導致金庫的 Pendle 部位被完全耗盡。

對於生產環境的金庫和收益策略，特別是那些整合複雜外部路由器的系統，開發者應：

• 將所有用戶提供的輸入（包括 calldata）視為不受信任並嚴格驗證。

• 在內部導出敏感參數（如 LP 金額和接收者），而不是接受用戶輸入。

• 通過強制執行內部會計記錄與外部執行結果之間的一致性，應用深度防禦。

未能做到這一點，可能會導致單次提款呼叫就危害協議持有的所有資產。

5. LZMultiCall 協議事件

簡要總結

2026 年 2 月 7 日，LZMultiCall 事件導致以太坊上約 14.2 萬美元的損失。

該事件並非由 LZMultiCall 合約本身的漏洞引起，而是由用戶誤用所致。LZMultiCall 是一個無狀態批次執行合約，並非設計用於託管資產或持有 ERC-20 授權。然而，一些用戶錯誤地向該合約授予了代幣授權。攻擊者隨後通過呼叫 execute() 並使用構造的 calldata 來呼叫 transferFrom()，利用這些懸空的授權耗盡了受影響用戶的代幣。

背景

LZMultiCall 是一個通用的批次執行工具合約。其預期目的是允許用戶將多個呼叫捆綁到單個交易中，將用戶提供的 calldata 轉發給目標合約。

關鍵在於，LZMultiCall 被設計為無狀態且非託管的。它不打算持有資產，用戶也不應授予它任何 ERC-20 授權。授予 LZMultiCall 的任何代幣授權都違反了其明確的使用假設並使用戶面臨風險，因為該合約可以代表呼叫者轉發任意呼叫。

漏洞分析

儘管 LZMultiCall 按設計運行，但一旦用戶錯誤地授予了 ERC-20 授權，其無需權限的 execute() 函數就變得可被利用。由於合約將任意 calldata 轉發給任何目標，攻擊者可以呼叫 execute() 並傳入在代幣合約上編碼為 transferFrom(victim, attacker, amount) 的 calldata，從而有效地耗盡任何未結授權。

攻擊分析

• 攻擊者呼叫 execute() 並使用針對代幣合約的構造 calldata，使用 transferFrom() 從那些錯誤地向 LZMultiCall 授予了授權的用戶那裡轉移代幣。

結論

此事件最終是由於違反了無狀態批次執行合約的明確使用假設所導致。LZMultiCall 從未打算託管資金或持有 ERC-20 授權。一旦用戶錯誤地授予了批准，合約無需權限的執行模型就允許任何呼叫者通過任意轉發呼叫耗盡這些授權。

對於與批次執行或 Multicall 風格合約互動的用戶和整合者：

• 絕不要向未明確設計用於託管資產的合約授予 ERC-20 授權。

• 將通用的轉發呼叫合約視為不受信任的執行面。

• 儘可能優先使用單次交易授權或無需授權的設計（例如 permit）。

即使在沒有協議漏洞的情況下，對合約信任模型的誤解也可能導致重大且不可逆轉的損失。

6. 未知協議事件 (2026 年 2 月 8 日)

簡要總結

2026 年 2 月 8 日，以太坊上的未知協議遭到攻擊，導致約 6.3 萬美元的損失。

根本原因是 Gnosis Safe 模組執行路徑中存在未經驗證的攻擊者控制輸入數據。一個註冊為 SafeModule 的工具合約 (0xF5E4) 公開了一個閃電貸回調，該回調解碼了任意用戶提供的數據並直接呼叫了 GnosisSafe.execTransactionFromModule()。因為模組發起的呼叫設計上繞過了簽名驗證，攻擊者得以執行任意經 Safe 授權的交易，償還了 Safe 在 Aave V3 上的債務，並將所有抵押品提取到攻擊者控制的地址。

背景

該協議架構圍繞著一個管理 Aave V3 槓桿部位的 Gnosis Safe。Gnosis Safe 支援模組化執行模型，指定的 SafeModules 被允許代表 Safe 執行交易，而無需所有者簽名。此設計旨在支援自動化、整合和高級策略。

在此設定中，合約 0xF5E4 被配置為 Gnosis Safe 的 SafeModule。該合約似乎是一個旨在支援基於閃電貸的部位管理工具。它實作了一個閃電貸回調 receiveFlashLoan()，該回調由外部流動性提供者在閃電貸執行期間觸發。

由於模組呼叫繞過了簽名驗證，模組邏輯的正確性和安全性至關重要：任何缺陷都會有效授予對 Safe 的不受限制控制權。

漏洞分析

SafeModule 0xF5E4 公開了一個閃電貸回調 receiveFlashLoan()，它解碼外部提供的 userData 並直接使用它來呼叫 GnosisSafe.execTransactionFromModule()。由於 0xF5E4 註冊為 SafeModule，其發起的呼叫繞過了簽名驗證。然而，receiveFlashLoan() 沒有驗證呼叫者，也沒有驗證解碼後的參數（例如目標地址、金額、calldata 或操作類型）。因此，攻擊者可以提供構造的 userData，使模組通過 Safe 執行任意交易，從而使其能夠償還 Safe 在 Aave V3 上的債務、提取所有抵押品並耗盡該部位獲利。

攻擊分析

• 步驟 1：攻擊者通過 Uniswap V4 採取閃電貸並將資金轉移到 GnosisSafe。

• 步驟 2：攻擊者使用構造的 userData 呼叫 Balancer 的 flashLoan()，未借入實際資產，並將 recipient 設定為 0xF5E4。

• 步驟 3：在 0xF5E4.receiveFlashLoan() 中，合約解碼了攻擊者提供的 userData。由於 0xF5E4 註冊為 Safe 模組，它繞過了簽名檢查，並呼叫 execTransactionFromModule() 以根據 userData 中嵌入的參數執行任意呼叫。

• 步驟 4：利用此功能，攻擊者償還了 GnosisSafe 在 Aave V3 上的債務並提取了所有抵押品，從而獲利。

結論

此事件最終是由於不安全地使用基於模組的執行，結合未經驗證的外部輸入導致。通過將任意的、由攻擊者提供的 userData 轉發給 execTransactionFromModule()，SafeModule 0xF5E4 有效地暴露了對 Gnosis Safe 的不受限制控制權。由於 Safe 模組在設計上繞過了簽名檢查，該缺陷導致了 Safe 的 Aave V3 部位被徹底危害。

對於依賴 Gnosis Safe 模組或類似特權執行框架的系統，開發者應：

• 將所有外部輸入（包括閃電貸的 userData）視為不受信任，並嚴格驗證。

• 將模組執行限制在一組定義明確的操作、目標和選擇器內。

• 避免使用將任意 calldata 轉發給特權執行函數的通用「工具」模組。

未能強制執行這些保障措施，可能會將單個工具合約轉變為完全的行政後門。

關於 BlockSec

BlockSec 是一家提供全端區塊鏈安全和加密合規服務的供應商。我們構建產品和服務，協助客戶在協議和平台的整個生命週期中進行代碼審計（包括智慧合約、區塊鏈和錢包）、即時攔截攻擊、分析事件、追蹤非法資金並履行 AML/CFT 義務。

BlockSec 已在知名國際會議上發表多篇區塊鏈安全論文，報告了多起 DeFi 應用程式的零日攻擊，攔截了多次駭客攻擊並挽回了超過 2000 萬美元的資金，並保護了數十億美元的加密貨幣安全。

• 官方網站：https://blocksec.com/

• 官方 Twitter 帳號：https://twitter.com/BlockSecTeam

• 🔗 BlockSec 審計服務 : 提交請求

• 🔗 Phalcon 安全 APP：預約展示

• 🔗 Phalcon 合規服務