重入攻擊

加密貨幣領域的重入攻擊是什麼？

重入攻擊是一種智能合約漏洞利用方式：外部合約會在第一次函式呼叫尚未完成前，再次呼叫存在漏洞的合約。

在加密貨幣領域，這類攻擊通常針對持有資金、追蹤餘額、處理提領、計算獎勵、管理金庫份額或與其他合約互動的智能合約。

核心問題在於，存在漏洞的合約尚未完成內部狀態更新，就將控制權交給另一個合約。

若攻擊者能在狀態尚未完成更新時重新進入該合約，就可能重複執行原本只允許執行一次的操作。

常見例子是提領函式先將加密資產傳送給使用者，之後才扣減使用者的記錄餘額。

若收款方是惡意合約，它可以利用 fallback 或 callback 邏輯，在餘額更新前再次呼叫提領函式。

如此一來，攻擊者可能提領超過其應得的金額。

OWASP 2026 年智能合約十大風險中的重入攻擊說明將重入定義為：合約執行外部呼叫後，被呼叫方在狀態尚未完全更新前，回頭呼叫原合約的情況。

重入攻擊是最知名的智能合約漏洞之一，因為它直接攻擊鏈上帳務的信任模型。

此類攻擊對去中心化金融尤其危險，因為智能合約經常管理大量流動性，並仰賴其他合約執行兌換、抵押、獎勵或價格資料等功能。

重入攻擊如何運作？

重入攻擊始於存在漏洞的智能合約對另一個合約或地址進行外部呼叫。

外部呼叫可能會傳送原生加密貨幣、轉移代幣、呼叫 Hook、要求回呼、執行策略，或與另一個協議互動。

存在漏洞的合約發出呼叫時，會暫時讓接收合約有機會執行自己的程式碼。

若接收合約由攻擊者控制，攻擊者便可趁此時回頭呼叫存在漏洞的合約。

由於合約尚未更新餘額、債務、份額、獎勵指數或鎖定旗標，其狀態值可能仍是舊資料。

攻擊者可利用這些舊資料重複提領、重複領取獎勵、超額借款或操縱計算結果。

攻擊會持續進行，直到合約資金耗盡、交易 Gas 用完，或防護機制阻止重複呼叫。

Solidity 關於外部呼叫的文件提醒，與另一個合約互動時，控制權會交給該合約；在第一次呼叫返回前，被呼叫的合約可能回頭呼叫原合約。

這項警告是重入防禦的基礎。

每次外部呼叫都應視為可能破壞合約假設的節點。

簡單的重入攻擊範例

假設有一個借貸合約會記錄每位使用者的存入餘額。

使用者向合約存入 10 ETH。

合約記錄使用者的餘額為 10 ETH。

之後，使用者呼叫提領函式，取回 10 ETH。

安全的合約會先將使用者餘額扣減至零，再傳送 ETH。

存在漏洞的合約則先傳送 ETH，之後才更新餘額。

若使用者實際上是惡意合約，傳送 ETH 時就會執行其 receive 函式。

該 receive 函式可以立即再次呼叫提領函式，此時存在漏洞的合約仍認為使用者有 10 ETH 餘額。

同一筆提領可能在單筆交易中反覆執行。

因此，智能合約邏輯的執行順序非常重要。

在傳統軟體中，小小的順序錯誤可能造成一般帳務錯誤。

但在持有加密資產的智能合約中，同樣的順序錯誤可能直接導致資產遭竊。

重入攻擊為何危險？

重入攻擊之所以危險，是因為智能合約常控制難以在攻擊後追回的資產。

公有區塊鏈的設計是執行有效交易，並保留交易歷史。

若惡意交易符合區塊鏈規則，卻利用合約漏洞，通常很難撤銷造成的損害。

Ethereum.org 智能合約安全指南說明，已部署的智能合約程式碼通常難以修改；由於區塊鏈具有不可竄改性，遭竊資產也很難追回。

因此，事前預防遠比事後修補重要。

重入漏洞可能耗盡流動性池、金庫、跨鏈橋、質押系統、NFT 市場、獎勵合約及借貸協議中的資產。

即使遭竊金額日後追回，使用者信任仍可能受損。

在加密貨幣領域，智能合約風險不只是開發者的問題。

它可能同時演變為使用者、流動性、治理及聲譽問題。

傳統重入攻擊

傳統重入攻擊是指攻擊者重新進入發出外部呼叫的同一個函式。

最常見的例子是存在漏洞的提領函式。

函式先確認使用者有餘額、將資金傳送給使用者，之後才更新餘額。

攻擊者的合約收到資金後，會在餘額扣減前再次呼叫同一個提領函式。

如此便形成迴圈，讓同一筆記錄餘額遭到重複使用。

傳統重入攻擊容易理解，但仍然危險，因為許多開發者仍會過早執行外部呼叫。

此外，現代合約的帳務通常比單純的存款與提領對應表更複雜，因此也增加了風險。

存在漏洞的函式可能涉及份額、債務倉位、獎勵乘數、金庫資產、流動性代幣或費用計算。

即使模式與傳統範例不同，核心問題仍可能相同。

跨函式重入攻擊

跨函式重入攻擊是指攻擊者重新進入同一合約中的另一個函式。

這比傳統重入更隱晦，因為遭攻擊的函式單獨檢視時可能看似安全。

例如，一個函式開始處理提領並發出外部呼叫。

外部呼叫期間，攻擊者可能呼叫另一個依賴相同餘額、份額或權限狀態的函式。

若第一個函式尚未完成狀態更新，第二個函式就可能讀取過時資訊。

這可能讓攻擊者在第一個操作完成前領取獎勵、轉移份額、借入資產或變更倉位。

跨函式重入說明，開發者必須考慮整個合約的不變條件，而非只保護明顯的提領函式。

合約不變條件是指每次有效操作前後都應維持成立的規則。

若外部呼叫可能暫時破壞不變條件，其他函式也可能成為攻擊途徑。

跨合約重入攻擊

跨合約重入攻擊是指回呼路徑經過多個合約。

這種情況可能發生在 DeFi 系統中，因為金庫、策略、路由器、代幣合約、預言機讀取器、質押模組及獎勵分發器會彼此互動。

金庫可能呼叫某項策略。

策略可能呼叫代幣或另一個協議。

被呼叫的合約可能觸發回呼，回頭連至金庫，或連至金庫所依賴的相關合約。

存在漏洞的狀態不一定位於發出第一次外部呼叫的同一個合約。

Solidity 安全注意事項指出，重入不只由 Ether 轉帳造成，也必須考慮多合約情境。

這點很重要，因為現代加密貨幣應用程式具有高度可組合性。

可組合性讓協議能相互連接並建立在彼此之上，但也會增加意外回呼的路徑。

唯讀重入攻擊

唯讀重入攻擊是指在狀態轉換尚未完成時，檢視或讀取函式回傳具有誤導性的資訊。

乍看之下似乎無害，因為檢視函式不會直接修改狀態。

然而，其他合約可能使用檢視函式計算價格、份額、抵押品價值、匯率或獎勵金額。

若某個合約處於中間狀態時觸發回呼，檢視函式可能回傳不應採信的暫時值。

攻擊者可能在依賴該數值的另一個合約中利用這項暫時值。

即使沒有透過一般提領函式直接耗盡第一個合約的資產，也可能因此造成類似預言機操縱的問題或帳務錯誤。

唯讀重入提醒我們，安全性不只取決於函式是否寫入儲存空間。

其他合約能否觀察尚未完成的狀態，並據此作出財務決策，同樣重要。

Hook 型重入攻擊

Hook 型重入攻擊是指代幣標準或協議介面在轉帳或操作期間，刻意呼叫接收方邏輯。

部分代幣及 NFT 標準包含接收方 Hook，讓合約在收到資產時執行對應邏輯。

閃電貸系統也會使用回呼，讓借款人能在同一筆交易中使用借入的流動性並償還。

這些 Hook 很有用，但也提供了回呼機會。

若合約假設代幣轉帳只是簡單操作、不會執行任何外部程式碼，這項假設可能不正確。

依代幣標準與實作方式不同，轉帳可能觸發接收方邏輯、操作員 Hook 或其他合約行為。

開發者應將每次外部代幣互動視為可能發生重入的節點，並加以檢查。

支援多種代幣、多種金庫資產或多項外部整合的合約尤其需要注意。

重入攻擊常見目標

提領函式最常成為重入攻擊目標，因為這類函式通常會將資金轉出合約。

金庫存入與提領函式也常成為目標，因為它們會更新份額餘額及資產帳務。

借貸協議可能成為目標，因為它們會追蹤抵押品、債務、利息、強制平倉門檻及借款餘額。

質押合約可能成為目標，因為它們會隨時間計算獎勵，並可能在領取獎勵時轉移獎勵代幣。

NFT 市場可能成為目標，因為購買及付款可能觸發代幣接收方 Hook 或外部版稅邏輯。

跨鏈橋可能成為目標，因為它們會管理跨鏈訊息、資產鎖定及釋放邏輯。

治理執行合約可能成為目標，因為它們在執行提案時會呼叫外部合約。

閃電貸借款人及提供者可能成為目標，因為其設計依賴回呼。

任何在完成內部帳務前就傳送價值或呼叫不受信任程式碼的智能合約，都應視為可能遭受重入攻擊的目標。

Checks-Effects-Interactions 模式

Checks-Effects-Interactions（檢查－狀態更新－互動）模式，是防範重入攻擊的重要方法之一。

Checks（檢查）是指合約先確認使用者是否有權執行操作。

Effects（狀態更新）是指合約在進行任何外部呼叫前，先更新自身內部狀態。

Interactions（互動）是指只有在檢查及狀態更新完成後，合約才進行外部呼叫。

以提領函式為例，合約應先確認使用者有餘額，再扣減餘額，最後才傳送資金。

如此一來，即使接收方嘗試重新進入，合約中的餘額也已更新。

Solidity 的 Checks-Effects-Interactions 文件將此模式描述為防範重入攻擊的常見方法。

這個模式簡單明瞭，但只要合約會與不受信任的外部程式碼互動，就不可忽略。

每當函式會變更狀態並呼叫合約外部程式碼，開發者都應養成預設採用此模式的習慣。

重入防護機制

重入防護機制是一種鎖定功能，可避免受保護函式在第一次呼叫完成前再次進入。

在 Solidity 合約中，通常會使用狀態變數，在函式執行期間標記其已進入。

若重入呼叫試圖進入相同的受保護路徑，防護機制就會拒絕該呼叫。

OpenZeppelin Contracts 5.x 的 ReentrancyGuard 文件說明，ReentrancyGuard 是一個提供 nonReentrant 修飾子的模組，可防止巢狀重入呼叫。

重入防護機制很有用，因為它能為高風險函式增添明確的安全層。

不過，防護機制不能取代正確的帳務設計。

開發者仍應採用 Checks-Effects-Interactions 模式，並檢查所有外部呼叫。

OpenZeppelin 也指出，由於 nonReentrant 防護機制只有一個，標記為 nonReentrant 的函式不能直接互相呼叫。

常見的解決方法，是將內部邏輯設為 private，再公開由 nonReentrant 保護的外部進入點。

暫存儲存與重入鎖

暫存儲存是較新的 EVM 功能，可用於僅在單筆交易期間存在的暫時值。

它可用於重入鎖，因為呼叫結束後，鎖定值不一定需要保存在永久儲存空間中。

OpenZeppelin 的 ReentrancyGuardTransient 文件介紹了採用暫存儲存的 ReentrancyGuard 版本，適用於支援 EIP-1153 的區塊鏈。

Solidity 暫存儲存文件指出，使用暫存儲存來設定在呼叫框架結束時清除的重入鎖是安全的。

這不代表所有合約都應自動採用暫存儲存。

開發者必須確認目標鏈支援所需功能，並確認鎖定值能正確清除。

若未妥善管理鎖定機制，可能破壞可組合性，或讓合約難以用於複雜交易。

最佳選擇取決於目標區塊鏈、編譯器版本、函式庫版本、升級模式及稽核要求。

為何 Transfer 與 Send 不是完整的防護方法？

過去的 Solidity 指引常將限制 Gas 的轉帳方式視為實用的重入緩解措施。

現代指引更加謹慎，因為 Gas 成本及 EVM 行為可能隨時間改變。

Solidity 地址成員文件提醒，send 與 transfer 已被棄用，並建議改用其他方法防範重入。

這點很重要，因為只依賴 Gas 配額可能造成錯誤的安全感。

合約應依靠正確的狀態邏輯確保安全，而不是假設收款方的 Gas 不足以執行危險操作。

較安全的作法是外部呼叫前先更新狀態、視情況使用重入防護機制、檢查回傳值，並謹慎設計提領流程。

開發者也應檢查仍將 transfer 或 send 視為主要重入防護方法的舊程式碼。

隨著協議規則、Gas 成本及常見攻擊技術演進，加密貨幣安全作法也會改變。

以 Pull Payments 作為防護

Pull Payment 模式讓收款方自行提領資金，而非由合約在其他操作期間主動推送資金。

這能降低風險，因為合約可以先記錄應付款項，再由收款方透過另一個步驟自行領取。

例如，市場可以先記錄賣方所得，而不是在買方購買交易中直接將資金傳送給賣方。

賣方之後可以呼叫提領函式領取資金。

若惡意收款方拒收款項，或在付款期間嘗試重入，此模式可限制可能造成的損害。

OpenZeppelin 安全工具文件說明，PullPayment 模式有助於避免重入攻擊。

Pull Payment 並非適用於所有設計，因為可能增加使用者操作步驟。

不過，若系統需要向許多使用者或合約付款，此模式可能非常實用。

緊急暫停控管

緊急暫停控管可讓獲授權帳戶或治理系統，在發生事件時暫停敏感功能。

若偵測到可疑行為或可能的重入漏洞，這有助於限制損害。

調查期間，暫停功能可能停止提領、存入、領取獎勵、新增借款或其他高風險操作。

OpenZeppelin 將 Pausable 列為常見的緊急應變機制，可在等待補救期間暫停功能。

暫停系統的設計必須謹慎，因為它會在治理與中心化之間帶來取捨。

若暫停權限過大，使用者可能擔心遭審查或權力遭到濫用。

若暫停權限不足或反應太慢，在攻擊進行期間可能無法發揮作用。

對高價值加密貨幣協議而言，緊急應變規劃應從安全設計初期就納入考量。

開發者如何偵測重入風險？

開發者可檢查合約中的每一次外部呼叫，以偵測重入風險。

外部呼叫包括原生幣轉帳、代幣轉帳、低階呼叫、介面呼叫、閃電貸回呼、NFT 接收方 Hook 及協議模組呼叫。

對每次外部呼叫，開發者都應確認內部狀態是否已更新。

開發者也應確認外部呼叫期間是否能呼叫其他函式，並讀取過時狀態。

開發者應檢查多個合約是否共享可能被回呼破壞的假設。

開發者應測試惡意接收合約，確認它會嘗試回呼每個公開及外部函式。

開發者應結合靜態分析、模糊測試、單元測試、不變條件測試及人工審查。

Solidity SMTChecker 文件將重入特性列為可針對外部呼叫未知程式碼進行分析的行為類別之一。

沒有任何單一工具能保證合約安全。

將自動化工具與經驗豐富的安全審查結合，才能更有效地偵測重入問題。

使用者如何看待重入風險？

大多數使用者無法在使用智能合約前完整稽核合約。

不過，使用者仍可留意安全作法是否完善，以降低風險。

協議應清楚說明稽核、漏洞獎勵計畫、緊急控管、升級權限及風險揭露資訊。

對於持有大量資產但缺乏公開審查的新合約，使用者應保持謹慎。

若協議提供異常高的收益，卻未說明報酬來源及智能合約風險，使用者也應小心。

即使使用者介面看起來精美專業，仍可能存在重入風險。

良好的介面無法證明底層合約邏輯安全。

使用者應避免將超出自身承受損失能力的資金，存入未經稽核或仍在實驗階段的合約。

使用者也應了解，稽核能降低風險，但無法完全消除風險。

重入攻擊與 DeFi 可組合性

DeFi 可組合性是指智能合約能像金融積木一樣彼此連接。

這是加密貨幣最強大的特色之一，因為錢包、金庫、借貸市場、兌換、衍生品、質押系統及治理工具都能互動。

然而，可組合性也會提高重入風險，因為單筆交易可能經過許多合約。

一個合約中看似安全的操作，可能觸發另一個合約中的複雜行為。

回呼可能延伸至第三個合約，改變第一個合約所依賴的數值。

價格、份額價值或餘額可能在暫時狀態下被讀取，而這種狀態原本不應被外部觀察。

因此，現代重入分析必須涵蓋完整的互動路徑。

開發者不應把每個合約視為獨立系統來審查。

開發者應檢查合約與路由器、代幣、金庫、閃電貸及外部策略結合時的行為。

重入攻擊與閃電貸

閃電貸可讓攻擊者在單筆交易中取得大量暫時流動性，因此可能使重入攻擊更具威力。

閃電貸本身並不是重入攻擊。

它是一種可用於合法套利、再融資、強制平倉及提升資本效率操作的工具。

不過，若存在漏洞的合約可在單筆交易中遭到操縱，閃電貸可能提供足夠資金，讓攻擊者有利可圖地執行漏洞利用。

閃電貸回呼系統也需要謹慎設計，因為這類系統會刻意將控制權交給另一個合約。

除非有充分理由，否則開發者應將每次回呼都視為來自不受信任外部程式碼的呼叫。

開發者應盡可能在回呼前更新狀態，並在回呼返回後驗證最終還款、餘額及不變條件。

閃電貸整合功能應使用惡意借款人合約測試，而不應只測試一般借款人範例。

重入攻擊與可升級合約

使用重入防護機制時，可升級合約需要特別謹慎。

可升級代理合約會將面向使用者的儲存空間與實作邏輯分開。

若重入防護機制使用儲存空間，開發者必須確保儲存空間配置正確，且在不同升級版本間相容。

錯誤變更儲存空間配置可能破壞防護機制，或損壞重要狀態變數。

建置可升級合約時，開發者應使用相容的函式庫。

開發者也應針對先前合約狀態測試升級，而不應只測試全新部署。

第一版合約可能安全，但後續升級若改變呼叫順序或新增外部整合，就可能引入漏洞。

升級審查應針對每個新增外部呼叫進行重入分析。

若協議持有大量資產，執行升級的治理或管理系統也應設置延遲、審查及緊急控管。

防範重入攻擊的最佳作法

進行外部呼叫前，先更新內部狀態。

在提領、領取、轉帳、兌換及帳務變更中採用 Checks-Effects-Interactions 模式。

對高風險外部進入點使用重入防護機制。

不要假設代幣轉帳一定是單純操作，因為部分代幣標準及實作可能觸發 Hook 或回呼。

不要只依賴 transfer 或 send 的 Gas 限制防範重入。

若直接付款會造成不必要風險，可採用 Pull Payment 模式。

除了傳統的同函式重入，也要檢查跨函式及跨合約重入。

使用會在每次外部呼叫期間嘗試重新進入的惡意接收合約進行測試。

使用不變條件測試，確認在複雜互動中，總餘額、份額、債務及儲備仍維持正確。

高價值系統應納入緊急暫停及事件應變計畫。

部署持有使用者資金的合約前，應進行獨立安全審查。

更新相依套件，並在變更主要版本前查看函式庫遷移說明。

開發者常見錯誤

常見錯誤之一，是傳送資金後才更新餘額。

另一個常見錯誤是只保護提領函式，卻讓相關函式暴露於跨函式重入風險。

另一個常見錯誤是認為代幣轉帳不會執行外部程式碼。

另一個常見錯誤是在單一合約使用重入防護機制，卻忽略與其相關、共用帳務假設的其他合約呼叫。

另一個常見錯誤是依賴過時的 transfer 與 send 假設，而未正確設計狀態邏輯。

另一個常見錯誤是在升級時新增外部整合，卻沒有重新檢查整體呼叫路徑。

另一個常見錯誤是認為檢視函式無害，即使其他合約會在複雜交易期間依賴其回傳值。

另一個常見錯誤是忘記惡意合約可能刻意採取與一般使用者不同的行為。

安全測試應假設存在敵意行為，而不只測試一般介面操作。

常見問題

重入攻擊是什麼意思？

重入攻擊是指惡意合約在第一次函式呼叫完成、狀態安全更新前，回頭呼叫存在漏洞的智能合約。

為什麼重入攻擊在加密貨幣領域很危險？

重入攻擊可能讓攻擊者在單筆交易中耗盡資金、重複領取獎勵、操縱帳務或破壞合約假設，因此十分危險。

重入攻擊只與 ETH 轉帳有關嗎？

不是。Solidity 文件提醒，重入不只與 Ether 轉帳有關，任何外部合約呼叫都可能產生回呼風險。

最知名的重入防禦方法是什麼？

Checks-Effects-Interactions 模式是最知名的防禦方法之一，因為它會在外部呼叫前先更新合約狀態。

什麼是 ReentrancyGuard？

ReentrancyGuard 是一種智能合約工具，提供 nonReentrant 修飾子，以避免巢狀呼叫進入受保護函式。

ReentrancyGuard 能防止所有重入漏洞嗎？

不能。ReentrancyGuard 有助於保護特定進入點，但開發者仍須確保帳務正確、呼叫順序安全，並審查跨合約互動。

什麼是跨函式重入？

跨函式重入是指第一個函式尚未完成時，攻擊者重新進入同一合約中的另一個函式。

什麼是唯讀重入？

唯讀重入是指操作尚未完成時，檢視函式回傳具有誤導性的暫時狀態，且另一個合約依賴該數值。

代幣轉帳會造成重入嗎？

會。部分代幣標準及代幣實作可能觸發 Hook 或回呼，因此應將代幣轉帳視為可能的外部呼叫並加以檢查。

使用者是否應避免所有智能合約，以防重入攻擊？

不必。使用者不需要避開所有智能合約，但應優先選擇具備完善稽核、清楚文件、主動監控及負責任風險控管的協議。

結論

重入攻擊是一種利用外部呼叫期間尚未完成狀態的智能合約漏洞利用方式。

攻擊者會在第一次呼叫完成前重新進入存在漏洞的合約，利用過時帳務取得超出允許範圍的價值。

傳統範例是反覆提領；現代重入也可能涉及跨函式呼叫、跨合約流程、唯讀狀態、代幣 Hook、閃電貸回呼及 DeFi 可組合性。

核心要點是：每次外部呼叫都應視為可能將控制權交給不受信任程式碼。

開發者可採用 Checks-Effects-Interactions、使用重入防護機制、避免不安全的付款模式、測試惡意回呼並檢查完整合約互動路徑，以降低重入風險。

使用者可選擇重視智能合約安全性的協議，並避免將大量資產存入未經稽核的系統，以降低曝險。

重入仍是加密貨幣安全中的重要概念，因為小小的邏輯順序錯誤可能演變成嚴重的金融漏洞利用。

了解重入有助於開發者打造更安全的合約，也能讓使用者理解智能合約稽核、安全模式及風險控管的重要性。