攻擊者從一個去中心化金融（DeFi）金庫中竊取了 600 萬美元，儘管該協議運行著核准地址白名單——一種旨在將資金轉移限制於預先授權目的地址的安全控制措施。漏洞賞金與安全平台 Immunefi 披露了此事件，並確認了 600 萬美元的損失。此一入侵事件暴露了金庫合約中白名單授權在實作與審計上的重大缺口。金庫合約將眾多用戶的存款集中於單一合約權限設定之後，這正是為何單一授權檢查的失效可能為存款人帶來巨大且即時損失的原因。

截至撰稿時，具體的協議、區塊鏈網路、交易雜湊值與攻擊向量尚未被公開證實；本文中超出這些事實的細節均未經證實。

核准地址白名單未能防止什麼

核准地址白名單的用意在於強制金庫提款或資產轉移僅能路由至固定的預先授權地址集合。理論上，無法將自己的地址加入該清單的攻擊者便無法提取資金。實務上，這項控制措施的有效性取決於管理清單更新的邏輯、管理該清單的管理員函數之存取控制，以及任何可呼叫特權金庫方法的互動合約。

常見的失效點包括：管理員金鑰遭入侵，使惡意地址能在資金被竊取前被加入清單；重入或回呼路徑完全繞過白名單檢查；或代理合約配置錯誤，其實作未執行與代理介面相同的限制。在缺乏經證實的事後分析報告之前，存款人尚無法確定此次攻擊者使用了哪條路徑。

為何白名單本身不足以保障金庫安全

白名單是一種周界控制，而非縱深防禦體系。在業界實務中，白名單式提款控制通常與許可制或機構級金庫流程相關，在這種模式下，更嚴格的營運控制伴隨著管理員金鑰集中風險——這正是此次事件中受到檢視的同一依賴。金庫安全還取決於合約是否具備可正常運作的暫停機制、緊急提款是否受時間鎖限制，以及白名單更新函數是否需要多簽批准或治理延遲。若其中任何一層缺失或配置錯誤，單一遭到入侵的金鑰或邏輯漏洞即可使白名單形同虛設。

評估設有白名單金庫的存款人應核實：誰控制著可更新白名單的管理員金鑰、白名單新增的時間鎖延遲為何、金庫合約是否位於可升級代理之後，以及獨立審計是否具體審查過授權路徑。一個被標榜為「白名單」卻未揭露上述資訊的金庫，所提供的保障比該標籤所暗示的更弱。這種模式與多鏈協議事件中所見的授權路徑問題並無不同——已修復的漏洞重新引入了可被利用的狀態。

存款人與營運方的即時檢查事項

任何在採用核准地址白名單的金庫中持有資金的存款人，應檢查自 Immunefi 披露以來，該協議是否已發布暫停或緊急公告。若受影響的協議尚未被公開點名，即時的做法是關注 Immunefi 披露資訊流以及該協議的官方治理論壇以取得更多細節。最能釐清情況的後續發展包括：點名受影響協議與鏈的修訂版披露、指明攻擊向量的事後分析報告，以及被竊資金在鏈上的任何可觀察動向。

金庫營運方應將此事件視為審計完整授權路徑的契機：不僅要確認白名單是否存在，還要確認進入金庫邏輯的每個入口是否執行相同的檢查、管理員函數是否受多簽保護，以及白名單更新交易是否會觸發監控警報。無法在異常轉移發生後數分鐘內觸發的暫停函數，無法提供任何實質保護。控制金庫參數的治理框架也應檢視金庫架構決策是否使存款人面臨管理員金鑰集中風險。

這 600 萬美元的損失印證了核准地址政策是必要但不足夠的控制措施。金庫安全需要多層執行機制：管理員函數的存取控制、狀變更操作的時間鎖、即時監控，以及包含可驗證暫停機制且經過測試的事件應變路徑。