在 2026 年前六個月，加密產業在 135 起經確認的安全事件中損失了 939.86 million 美元。乍看之下，原因似乎很直接：專案仍在將未經審核的程式碼部署到 mainnet，使協議金庫暴露於熟悉的攻擊手法之下。

然而，數據顯示的情況更令人擔憂。

超過半數遭攻擊的專案，損失合計超過 721 million 美元，都已完成安全稽核。但在這些案例中，有 94.4% 的攻擊並不是因為已審查的 smart contract 漏掉了 reentrancy bug。相反地，攻擊者是透過稽核人員未檢視的區域入侵：

• 私鑰遭盜
• 前端腳本遭劫持
• 雲端基礎設施外洩
• 未審查的鏈下 relayer

這些發現來自 ack3 發布的 H1 2026 綜合安全報告。ack3 是一家以 AI 為核心的網路安全公司，前身為 Ackee Blockchain Security。ack3 表示，自 2021 年以來已完成 237 次協議審查，並觀察到安全邊界已從孤立的 Solidity 檔案擴展到完整的協議架構。為此，該公司結合人工審查、基於 Wake 的 fuzzing、鏈下威脅建模，以及可追蹤跨元件依賴關係的專有 AI 掃描。

報告指出，Web3 在風險評估上的核心弱點在於：業界常把「已稽核」視為永久且二元的狀態，而攻擊者則把協議架構視為彼此連動、持續變化的 Web 服務。

ack3 創辦人 Josef Gattermayer 表示：「稽核是一個時間戳記與邊界，不是終身保固。」他說，「舊問題是：『有沒有稽核？』有用的問題則是：『到底稽核了什麼、什麼時候稽核的，以及之後發生了哪些變化？』合約報告無法保護外洩的簽署金鑰、遭入侵的前端，或是已不再符合受審查程式碼的舊版部署。」

2026 年上半年損失概況

在 2026 年前六個月，Web3 安全生態系共記錄 135 起經確認的安全事件，從去中心化協議及其使用者手中流失 939.86 million 美元。ack3 資料集中的每一起攻擊都符合嚴格的雙來源驗證標準，涵蓋鏈上與鏈下的入侵。

按歷史稽核狀態分類這 135 起事件時，分布看起來相當平均：

• 已稽核受害者： 68 起事件（占總數 50.4%）鎖定了在遭攻擊前至少完成一次、且可公開驗證的安全審查的專案。
• 未稽核受害者： 35 起事件（25.9%）影響了未接受正式第三方安全審查的協議。
• 稽核狀態未知： 32 起事件（23.7%）涉及在資料集截點時無法確認稽核歷史的專案。

稽核幻覺

乍看之下，這些數字可能會讓人以為安全審查只能提供有限保護。但若改以財務損失而非事件數量來衡量，問題的規模就更加清楚。

已稽核協議在 H1 2026 損失的 939.86 million 美元中占 721.24 million 美元，也就是全部被盜資本的 76.7%。未稽核專案與稽核歷史未知的專案合計損失 218.62 million 美元。

這個差距揭示了 ack3 所稱的稽核幻覺。資本往往會流向那些展示安全徽章的專案。機構配置方、yield farmer 與散戶交易者常把稽核報告視為綠燈，將流動性導入外觀完善的協議。

這便形成一個悖論：稽核吸引資本，而資本又使已稽核協議成為更高價值的目標。雖然仔細的程式碼審查可以阻擋尋找明顯 Solidity 漏洞的機會型攻擊者，但成熟的威脅行為者不會因為看到稽核徽章就退場。相反地，他們會把焦點從受審查的 smart contract 轉向周邊仍未受監控的基礎設施。

H1 2026 的情況顯示，攻擊者已不再試圖正面突破已稽核程式碼的大門，而是改走從未審查的側門。

範圍落差：680 million 美元是如何消失的

Web3 安全中最危險的誤解之一，就是把 smart contract 稽核等同於整體系統防護。實務上，一份稽核通常只涵蓋特定 commit hash 與一組明確定義的 Solidity 或 Rust 檔案。它不涵蓋部署環境、開發者工作站、雲端基礎設施、DNS 記錄，或用來管理協議參數的私鑰。

ack3 的研究顯示，這個差異——所謂的「範圍落差」——正是幾乎所有被盜資本真正消失的地方。在 H1 2026 遭入侵的 68 個已稽核協議中，有 46 個是透過完全超出其公開稽核範圍的攻擊向量受害。這 46 起事件造成 680.97 million 美元損失，占已稽核受害者總財務損害的 94.4%。

數量與價值的落差

若將事件數量與實際美元損失對照，這種差異會更加明顯。

攻擊路徑直接發生在已稽核程式碼內的事件，占 68 起已稽核入侵中的 20 起，按數量計約為 29.4%。但這 20 起落在範圍內的攻擊，攻擊者只獲得 35.21 million 美元損失，也僅占已稽核總損失的 4.9%。

這個對比相當鮮明。傳統程式碼稽核在發現災難性的 smart contract 漏洞方面，看起來確實有一定成效，將範圍內損失壓在總損失的 5% 以下。但協議團隊卻仍把後門大開，讓剩餘 94.4% 的損失來自基礎設施與營運層面的入侵。

現代攻擊面剖析

攻擊者已意識到，smart contract 往往是整條鏈中最強的一環，因此他們系統性地轉向程式碼周邊的營運面。

ack3 指出，造成範圍外資金流失的四種常見營運攻擊向量如下：

私鑰與簽署權限遭盜： 管理金鑰、multisig 簽署者與營運熱錢包，仍是快速清空資產的最快路徑。一旦簽署權限因釣魚或金鑰管理不當而遭入侵，攻擊者就能透過合法的協議功能升級合約、修改參數或觸發緊急鑄造，完全繞過鏈上邏輯檢查。

前端腳本注入與 DNS 劫持： 攻擊者不破壞鏈上邏輯，而是入侵使用者信任的介面。透過控制 DNS 記錄，或經由第三方網頁依賴注入惡意 JavaScript，攻擊者可在使用者與看似合法的 UI 互動時，調換目標地址或誘使使用者為惡意 spender 簽署授權。

CI/CD 流水線與雲端基礎設施憑證： 攻擊路徑越來越常經由 GitHub Actions、雲端環境變數與建置流水線。硬編碼的 secrets 或外洩的 API key 可能讓攻擊者在程式碼觸及區塊鏈之前，就篡改建置產物或存取基礎設施資產。

未審查的鏈下 prover、relayer 與跨鏈基礎設施： 現代 DeFi 協議高度依賴鏈下系統，包括 prover、oracle relayer、零知識 sequencer 與跨鏈訊息橋。這些服務通常不在標準合約稽核範圍內，卻決定了觸發鏈上執行的輸入值。當 relayer 或 prover 出現故障時，smart contract 只是照指示處理錯誤的狀態更新。

時點式保證與老化問題

即使攻擊命中了明確屬於稽核範圍內的程式碼，ack3 的資料也指出 Web3 安全實務中的另一項弱點：保證衰減。

稽核報告不是持續性的防護罩；它只是系統在某一時點的靜態截圖。但協議往往把兩年前的 PDF 報告當作當前安全性的證明。ack3 的研究顯示，即使底層 smart contract 邏輯未被改動，歷史審查的保護價值也會隨時間遞減。

安全性的衰減速度

在 20 起攻擊路徑直接落入協議已稽核範圍的事件中，有 17 起發生在最相關稽核之後至少六個月。從稽核日期到攻擊發生的中位時間為 18 個月，間隔最短三個月，最長達 56 個月。

只有 3 個協議是在收到稽核報告後六個月內遭到範圍內攻擊。大多數範圍內失敗都發生在原始審查完成很久之後：

• 少於 6 個月： 3 起事件（15% 的範圍內案例）
• 6 至 24 個月： 9 起事件（45%）
• 24 個月以上： 8 起事件（40%）

這項分布凸顯出一個明顯結論：在快速變動的生態系中，稽核報告的相關性會迅速下降。年齡本身不會造成 smart contract bug，但它衡量的是程式碼在周邊一切都在變化時，持續暴露了多久。因此，ack3 認為，加密協議應該定期完成多次稽核，而不應依賴一份兩年前的報告。

AI 作為攻擊倍增器，以及走向「活性保證」的轉變

專門化的 AI 工具已永久改變安全研究的速度與規模。雖然 ack3 的 H1 2026 資料集沒有把任何具體事件歸因於自主 AI agent，但報告指出，攻擊者正把 AI 當作營運層面的倍增器，這已改變整體威脅格局。

新的威脅現實

在一份經過大量審查的 Solidity 合約中找出複雜的 reentrancy bug，仍然需要相當的技術與時間。在未索引的鏈下儲存庫中找出暴露的 enclave key，或在前端建置流水線中辨識未固定版本的第三方腳本，過去則需要繁瑣的人工偵察。

AI 模型已將這些成本壓到近乎為零。

攻擊者如今利用 AI 工具快速讀入整個協議生態系，建立跨儲存庫關聯，追蹤鏈下到鏈上的參數流，並探查雲端基礎設施、前端傳遞網路與 smart contract 之間未受監控的接縫。

隨著 EVMbench 等基準主動衡量 AI agent 在漏洞偵測、自動修補與攻擊合成方面的表現，誰能以最快速度掃描最廣的攻擊面，誰就擁有不對稱優勢。如果防守方只看一個 smart contract 資料夾，使用 AI 的攻擊者通常會先找到周邊的營運弱點。

取代 PDF 產物

把靜態 PDF 稽核報告當作永久安全憑證，在 ack3 看來已是生存風險。靜態文件無法在開發者把 API secret 提交到公開儲存庫時即時警示團隊，也無法評估上游流動性池更改手續費結構後，smart contract 會如何運作。

要在攻擊向量能以 AI 驅動速度跨越元件邊界的環境中生存，協議必須從時間點式審查轉向活性保證。ack3 為這項轉型提出三個核心支柱：

1. 以即時、動態的全系統資產登錄，取代靜態合約清單，持續盤點：

   • 鏈上 smart contract 部署與 proxy 地址
   • 鏈下基礎設施、relayer、prover 與 oracle 流水線
   • 管理角色、multisig 簽署者與金鑰管理機制
   • 網頁依賴、CDN 與前端建置流水線

2. 不要依固定的年度時程更新保證，也不要假設它是永久有效的。協議需要明確的營運觸發條件，一旦發生就立即將程式碼或基礎設施標記為需針對性再稽核，包括：

   • 新 proxy 實作或參數更新的部署
   • 金鑰輪替、管理角色移轉或 multisig 門檻變更
   • 新跨鏈橋、oracle feed 或上游流動性協議的整合
   • 在同業協議中發現新的攻擊類別或利用向量

3. 在 mainnet 部署前後，同時運用機器分析與人工專業。自動化 AI 掃描器與基於 Wake 的 fuzzing 引擎，適合進行廣泛機器搜尋、跨元件依賴追蹤、邏輯漂移偵測，以及監控即時基礎設施中的異常狀態變化。接著由人工安全工程師負責驗證可利用性、評估經濟威脅模型，並確認商業邏輯。

目標不是消除稽核，而是讓保證能跟上系統變化。在這種模式下，二元的「已稽核」標籤會回到它本來應有的樣子：一個持續的過程，而非靜態徽章。

結論：重新思考 Web3 的安全姿態

H1 2026 損失的 940 million 美元清楚說明一件事：把歷史時間點上的稽核當成永久綠燈，是營運上的疏失。smart contract 並不是存在於真空之中。只覆蓋 Solidity 檔案、卻忽略前端依賴、管理簽署金鑰、雲端基礎設施與鏈下 prover 的稽核，不能構成完整的安全保證。

隨著 Web3 的資本配置逐漸成熟，用來評估風險的機制也正從時間點式審查轉向整體系統監控。Web3 安全的未來屬於那些把保證視為持續營運紀律的團隊。繼續躲在靜態 PDF 報告後方的團隊，將仍是棋盤上價值最高的目標。