損失約 1600 萬美元：DxSale、SquidRouterModule 等項目 | BlockSec 週報

在過去的一週（2026/05/27 - 2026/05/30）中，BlockSec 在多個區塊鏈生態系統中識別出多起攻擊事件。下表列出了 5 起重大事件，預估總損失約為 1,600 萬美元。

*其他說明：

• 在 Stake DAO 事件中，攻擊者竊取了部署者的私鑰，並將其用於重新配置 Arbitrum 上 vsdCRV 合約的 LayerZero v2 OFT 對等節點，從而鑄造了 5.4 兆個 vsdCRV。由於 DEX 流動性有限，在資金池耗盡前僅套現約 9.1 萬美元。
• 在 Alephium 事件中，除了約 30 萬美元的跨鏈橋託管資產（以太坊上的 USDT、USDC、WETH、WBTC 以及 BNB Chain 上的 USDT、WBNB）被盜外，攻擊者還在以太坊上鑄造了 1,370 萬個無抵押的 wALPH。跨鏈橋隨後被關閉，阻止了攻擊者透過 Alephium 橋贖回或轉移這些代幣。

我們選取了兩起事件進行深入分析：

• The SquidRouterModule 合約：與 CrossCurveFi 的利用手法類似，它重複了相同的集成錯誤，顯示出若在沒有深入理解和嚴格安全審核的情況下對跨鏈邏輯進行分叉（Fork），可能會將繼承來的複雜性迅速轉化為繼承來的風險。
• DxSale：其漫長的攻擊時間線表明，未被利用的舊合約並不一定安全；協議必須持續審核休眠的基礎設施，最小化權限訪問，且絕不能將多年的平靜誤認為是安全性的證明。

每週亮點：DxSale

此事件被選為每週亮點，是因為結合了存續多年且未修補的鎖倉合約與洩露的部署者私鑰，這展示了一種重複出現的模式：將部署時期的代碼視為永久安全、缺乏持續審計或權限輪換的協議，始終攜帶著隨時可能被利用的潛在風險。

2026 年 5 月 29 日，BNB Chain 上的代幣銷售與流動性鎖倉平台 DxSale 遭到攻擊 [1]，損失約 730 萬美元。其代幣提領函數缺少了三處狀態更新，導致任何擁有有效鎖倉記錄的用戶都可以重複提領並耗盡共享池，且無需任何所有者權限。儘管透過 EIP-7702 授權對 DxSale 部署者私鑰進行單獨的竊取並非觸發此次利用的必要條件，但它透過允許費用操縱並阻止其他用戶建立新的鎖倉，進一步放大了攻擊者的效率。

背景

DxSale 是 BNB Chain 上的代幣銷售與流動性鎖倉平台。其 DxLock 組件允許項目開發者將 LP 代幣鎖定在具有時間限制的保管庫中，向投資者保證流動性無法被捲款潛逃（Rug-pull）。

核心鎖倉機制運作方式如下：用戶將代幣存入鎖倉合約，建立由呼叫者地址與代幣 ID 組合索引的鎖倉記錄。每條記錄儲存了鎖倉是否存在、代幣目前是否處於鎖定狀態、鎖定金額、解鎖時間戳以及代幣地址。當鎖定期結束時，用戶呼叫 unlockToken(tokenId) 來提取代幣。

由於鎖倉合約在共享餘額中同時為多個用戶保管代幣，必須透過獨立的鎖倉記錄準確追蹤個別的份額。整個資金池的安全性取決於每次提領是否正確驗證了呼叫者自身的記錄，並在轉帳後進行更新。

漏洞分析

漏洞合約（0xeb3a...e449）中的 unlockToken 函數包含三個複合缺陷，每一個皆為缺少狀態更新或檢查：

function unlockToken(uint256 tokenId) public nonPayable {
    require(_increaseLockTime[msg.sender][tokenId].field0_0_0);  // 鎖倉存在
    require(_increaseLockTime[msg.sender][tokenId].field0_1_1);  // 代幣已鎖定
    require(_increaseLockTime[msg.sender][tokenId].field2);       // 金額 > 0

    if (block.timestamp > _increaseLockTime[msg.sender][tokenId].field3) {
        _increaseLockTime[msg.sender][tokenId].field0_1_1 = 0;
    }

    v0, v1 = _increaseLockTime[msg.sender][tokenId].field5_0_19.balanceOf(this);
    require(v1 >= _increaseLockTime[msg.sender][tokenId].field2);
    v2, v3 = _increaseLockTime[msg.sender][tokenId].field5_0_19.transfer(
        msg.sender, _increaseLockTime[msg.sender][tokenId].field2
    );
}

1. 未強制執行鎖定期。鎖定期僅由 if 語句保護，而非 require。當在解鎖時間戳之前呼叫時，該函數只是跳過了清除鎖定標誌，而不是回退交易。這意味著無論鎖定期如何，代幣都可以隨時提取。

2. 鎖定金額從未歸零。在將代幣轉移給呼叫者後，函數並未將 field2（鎖定金額）歸零。隨後的每一次呼叫都會讀取相同的原始數值，並再次提取相同數量的代幣，從而形成無限提領迴圈。

3. 使用共享餘額檢查而非個別份額檢查。balanceOf(this) 呼叫驗證了合約的總代幣餘額，而非呼叫者的個人份額。只要合約中仍持有足夠的總代幣，擁有小額鎖倉份額的呼叫者就能耗盡整個共享池。

綜合來看，這三個缺漏的狀態更新移除了函數中所有的退出條件：呼叫永不會提前回退、提領金額從未減少，且餘額檢查在合約完全清空前絕不阻攔。任何創建過鎖倉記錄的用戶都可以利用此 Bug；核心的資金耗盡過程完全不需要任何管理員所有者權限。

攻擊分析

DxSale 部署者帳戶（0x47bacf93）透過 EIP-7702 授權運作，自 2026 年 4 月 15 日起便表現出異常活動，包括大規模的所有權轉移、費用變更以及在多個 DxSale 合約上的 LP 解鎖操作。2026 年 5 月 26 日，部署者將受害鎖倉合約（0xeb3a...e449）的所有權轉移至攻擊者合約（0xc457...fa69）。兩天後，攻擊者執行了五步耗盡流程。

以下分析基於代表性交易 0x437b26...c1b303：

• 第一步：攻擊者在 PancakeSwap 上以 BNB 兌換 BNBC 代幣，並提供流動性以建立一個新的 Cake-LP (BNBC/WBNB) 配對，獲得約 0.323 個 LP 代幣。

• 第二步：利用先前獲取的所有權權限，攻擊者呼叫 changeFees(1) 將鎖倉創建費用設定為 1 wei，隨後呼叫 createLocker 將約 0.323 個 LP 代幣存入一個新的鎖倉記錄（tokenId=131）。緊接著，攻擊者呼叫 changeFees(10^36) 將費用提高至天價，防止其他用戶創建新的鎖倉。

• 第三步：攻擊者呼叫攻擊函數（0x11b432b4），在單次交易中組織了重複的 unlockToken 呼叫。在多筆交易中，攻擊者系統性地耗盡了鎖倉合約：0x437b26...c1b303 透過 tokenId=131 耗盡了 161.4 個 LP 代幣；隨後 0x82f541...a9fa73 與 0x5dd61f...4298aa 耗盡了額外的鎖倉記錄；0xac8f5e...d36df9 則透過 tokenId=319 在 478 次呼叫中耗盡了 260.3 個 LP 代幣。

• 第四步：攻擊者在 PancakeSwap 上呼叫 removeLiquidity，將耗盡所得的 LP 代幣拆解還原為底層資產（BNBC 和 WBNB）。

• 第五步：攻擊者將底層代幣透過 PancakeSwap 兌換為 WBNB 和 BUSD，並將所得轉移至外部地址。BSCScan 顯示，該攻擊者合約在 4 天內（2026-05-28 至 05-31）執行了 123,447 筆交易。

結論

此次事件的根本原因在於 unlockToken 中缺少了三項關鍵狀態更新。每個缺陷都有直接的修正方法：使用 require 而非 if 來強制鎖定期，每次提領後將鎖倉金額歸零，並檢查呼叫者的個人配額而非合約總餘額。這些缺陷足以完成攻擊，任何建立過鎖倉位置的用戶都可以透過重複呼叫耗盡整個共享池，且無需任何所有者權限。

DxSale 部署者先前透過 EIP-7702 權限委託受損雖非此次利用的必要條件，但卻放大了攻擊者的效率。透過轉移所有權及操縱費用，攻擊者創建了幾乎零成本的鎖倉位置並阻擋了合法用戶創建競爭鎖倉的可能。在營運層面，協議必須對舊合約（特別是持有用戶資金的合約）進行持續審計，並避免對管理功能進行單金鑰託管。長年未發生事故的運行歷史並不能印證未審計代碼的安全性。

參考資料

• [1] DxSale 公告

本週更多事件

The SquidRouterModule 合約

2026 年 5 月 27 日，一個名為 SquidRouterModule 的未知合約在以太坊上因輸入驗證不當遭到攻擊 [1]，造成約 320 萬美元的損失。根本原因是對 Axelar Bridge 組件的誤用，與早期的 CrossCurveFi 攻擊模式相似 [2]。合約未透過 Axelar Gateway 正確驗證跨鏈訊息，導致攻擊者能夠偽造負載，進而授權並將受害者的代幣兌換為預先設置的惡意資金池資產。另一個部署了虛假代幣並為資金池提供流動性的攻擊者地址隨後移除流動性，提取了真實資產。此次攻擊影響了 86 個 Safe 錢包。儘管名字如此，但 SquidRouterModule 並非由 Squid 協議團隊建立、部署或營運 [3]。

背景

該合約是一個為 Safe 錢包設計的跨鏈交易服務模組，構建於 Axelar 跨鏈協議之上。合約提供 expressExecuteWithToken 函數，支援在跨鏈訊息確認前提前執行交易。用戶在使用此服務前，必須預先授權其 Safe 錢包對該合約的 APPROVE 與 SWAP 權限。當 expressExecuteWithToken 被呼叫時，合約會解碼負載中的操作指令，並呼叫 Safe 錢包的 execTransactionFromModule 來執行代幣授權與交換操作。

漏洞分析

漏洞合約（0x1f1d...23ca）中的 _executeWithToken 函數僅檢查了 srcAddress 是否等於 squidRouter 常數。然而，srcAddress 是呼叫者提供的參數，而 squidRouter 是一個任何人都可以在合約中讀取到的不可變字串。這使得攻擊者能夠輕易繞過檢查，並以任意負載內容執行 _processPayload 函數。

相比之下，合法的 Squid Router 合約的 executeWithToken 函數會呼叫 gateway.validateContractCallAndMint()，並且若 Axelar 驗證者網路尚未確認交易，則會返回 NotApprovedByGateway() 錯誤。

該漏洞合約在 expressExecuteWithToken 路徑中並未強制實施任何此類閘道驗證。結合 Safe 錢包用戶已預先授權給模組的 APPROVE 和 SWAP 權限，偽造的負載可以直接操作受害者的資金。

攻擊分析

以下分析基於交易 0xd29d1c...3bb854。

攻擊發生前，另一個攻擊者地址部署了一個虛假代幣（0xe6Ff...3512）並建立了多個 Uniswap V3 資金池，將虛假代幣與多種高價值代幣（如 USDC、ENA、USDT）配對，並使用虛假資產作為流動性基礎。

• 第一步：攻擊者偽造 malicious calldata 並呼叫漏洞合約的 expressExecuteWithToken 函數，使用已知的 squidRouter 地址作為 sourceAddress 以繞過驗證檢查。透過受害者已預先授權給模組的 APPROVE 和 SWAP 權限，偽造的負載強迫受害者的 Safe 錢包向 Uniswap 資金池進行代幣授權。

• 第二步：利用這些被強迫執行的授權，負載將受害者的代幣透過相應的惡意資金池兌換為毫無價值的虛假代幣。

攻擊者透過多筆交易重複此方法，針對 86 個曾授權過該漏洞合約的 Safe 錢包進行攻擊。隨後，部署虛假代幣並設置資金池的攻擊者地址執行移除流動性的操作，將真實資產提走，最終獲利約 320 萬美元。

結論

此次事件由跨鏈訊息處理路徑中的輸入驗證不當所引起。唯一的安全檢查依賴於一個由呼叫者可控的參數與公開可讀的常數進行比較，無法提供任何實際保護。結合 Safe 錢包用戶預先授權的 APPROVE 和 SWAP 權限，攻擊者能夠偽造跨鏈訊息並竊取用戶資金。

該事件與 CrossCurveFi 的利用手法相似 [2]：兩者皆涉及未正確驗證接收到的跨鏈訊息的 Axelar Bridge 集成。在集成跨鏈訊息基礎設施時，目標合約必須透過跨鏈橋自帶的授權機制獨立驗證訊息的真實性。跳過此類驗證並依賴攻擊者可控的輸入，會使集成變成一個開放的攻擊面。

參考資料

• [1] Phalcon Alert: SquidRouterModule 漏洞利用
• [2] Phalcon Alert: CrossCurveFi 攻擊模式
• [3] Squid Router 澄清說明

關於 BlockSec

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

BlockSec 已在各大頂尖會議中發表多篇區塊鏈安全論文，披露了多項 DeFi 應用程式的零日漏洞，攔截了多起駭客攻擊並挽回超過 2,000 萬美元的資金，並保障了數十億美元之加密貨幣的安全。

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

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

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

• 🔗 Phalcon Security APP: 預約產品演示

• 🔗 Phalcon 合規服務