以太坊客戶端修復可能導致 ETH 收益被重定向的漏洞
Teku 和 Besu 更新突顯外部基礎設施安全的重要性
2026 年 10 月下旬，以太坊共識客戶端 Teku 和執行客戶端 Besu 發布了安全更新，以修復與印度公司 eMudhra 被入侵的憑證授權機構金鑰相關的漏洞。此缺陷可能允許攔截特定 HTTPS 連線的攻擊者偽裝驗證者使用的外部服務，並重定向區塊獎勵或獲取敏感簽名。研究人員發現，八個 eMudhra 中間憑證授權機構的私鑰是使用不足的隨機性生成的，使得這些私鑰可從公開憑證本身恢復。由於兩者使用的 Java 運行時預設不檢查憑證撤銷，一些 Docker 鏡像和安裝在瀏覽器和主要作業系統封鎖後仍繼續信任受影響的憑證鏈。避免使用 HTTPS 端點的預設主網 Teku 設定不受影響，開發人員報告未發現確切的利用案例。
這些補丁從更新的 Docker 鏡像中移除了對受影響根證書的信任，而運行獨立二進制文件的操作員則需單獨處理其本地 Java 信任存儲。此事件突顯了外部基礎設施依賴性如何在核心協議保持安全的情況下，為質押操作帶來狹窄但高影響的風險。Teku 和 Besu 的快速響應表明，以太坊的客戶端多樣性與主動安全實踐能夠在證書相關威脅大規模影響驗證者獎勵之前加以遏制，前提是操作員應用可用的更新並審查其外部連接配置。
eMudhra 中間金鑰中的隨機性不足導致可恢復的私有資料
研究人員於2026年10月17日發現問題，當時確定eMudhra的八個中間證書授權機構的私鑰在生成時熵值過低。這些密鑰可從公開證書中有效恢復，此狀況自2025年4月的密鑰生成儀式以來一直存在。其中六個中間機構支援TLS連線，另外兩個與代碼簽名相關。一旦私密資料外洩，攻擊者便可發出欺詐性證書，而仍信任受影響授權機構的軟體會將其視為有效。eMudhra於10月18日撤銷了這些中間機構。主要平台迅速作出回應：瀏覽器和作業系統於10月17日至20日之間開始封鎖這些證書，而微軟則於10月26日至27日發佈了進一步的Windows和Edge更新，將相關根證書從其信任清單中移除。此密碼學故障本身並非以太坊協議的問題，但由於Teku和Besu在其節點進行任何HTTPS連線時依賴Java證書驗證，因此產生了影響。Java預設跳過撤銷檢查的行為，使某些安裝環境比瀏覽器環境暴露更久。因此，此事件說明了單一證書授權機構的操作錯誤如何蔓延至依賴標準TLS信任儲存的專用基礎設施。
密鑰的恢復並不需要複雜的密碼分析；由於隨機性不足，一旦檢查了公鑰證書，推導過程便變得直接。微軟於10月26日發布的公告確認，這些密鑰可用於創建看似來自可信權威的證書，可能導致網站或服務的偽冒。對於以太坊運營者而言，實際後果是：任何依賴HTTPS端點、遠程信標節點、外部簽名器、區塊構建者或中繼的驗證器配置，若其底層Java運行時仍信任受損的證書鏈，便可能接受偽造的證書。以太坊客戶端使用的點對點網絡不受影響，因為它不依賴這些證書授權機構。可恢復的密鑰與未吊銷的Java驗證相結合，創造了一個窗口期，在此期間，位於網絡路徑上的中間人攻擊者可向客戶端軟件呈現可信的身份。客戶端團隊的回應是，從其Docker鏡像中移除相關的根證書，而非僅僅等待基礎Java更新，以確保獲取新鏡像的運營者能獲得強化後的信任存儲。這種分層應對措施——包括CA吊銷、平台封鎖和客戶端特定鏡像更新——有效縮小了大多數質押設置的實際攻擊面。
偽造證書如何改變區塊提議與手續費接收者行為
Teku 的安全公告詳細說明了當攻擊者能夠提供客戶端接受的偽造證書時，可能出現的具體攻擊路徑。其中一種情境涉及冒充驗證者用於協調的遠端信標節點。如果連線被攔截且偽造證書被接受，驗證者可能會收到關於其準備提案區塊的操縱資訊。在這種情況下，客戶端可能會構建並簽署一個費用接收地址指向攻擊者控制帳戶而非操作者指定地址的區塊。該區塊中的交易費用及任何優先小費將會流向攻擊者。公告還指出，外部簽名服務會將驗證者密鑰分開儲存，並在請求時返回簽名。能夠冒充此類簽名者的攻擊者，可獲取用於敏感操作的簽名，包括 影響獎勵流向的變更。Teku 將外部簽名者的情況列為較嚴重的配置之一，儘管在某些設定中，雙向 TLS 認證會將影響限制為拒絕服務，而非簽名遭竊取。
其他暴露的連接類型包括執行客戶端、區塊構建者、中繼器以及提供驗證者配置資料的服務。在每種情況下，核心風險都相同：客戶端軟體將偽造的憑證視為合法，因此接受會更改建議區塊內容或密鑰處理方式的資料或指令。此漏洞在正常運作下並未授予對驗證者簽名密鑰的直接存取權限；相反，它破壞了驗證者所依賴的外部服務的完整性。由於以太坊區塊獎勵和手續費是根據建議區塊中嵌入的地址支付的，因此在提案階段的成功操縱即可轉移價值，而無需移動已賺取的資金。目前尚未報告任何針對這些路徑的利用行為，且配置中不含 HTTPS URL 的預設主網 Teku 安裝仍不在受影響範圍內。然而，詳細的情境清楚說明了為何客戶端團隊將此問題視為需要立即更新 Docker 映像，即使底層協議和點對點層並未受到影響。
Teku 26.10.3 從 Docker 信任儲存中移除受損的根證書
Teku 於 2026 年 10 月 27 日發佈了版本 26.10.3，專門用於解決與 eMudhra 相關的風險。發行說明指出，Docker 鏡像不再信任 emSign ECC Root CA – G3、emSign Root CA – G1、emSign Root CA – G2 或 AAA Certificate Services 的根憑證。這些根憑證已在中間機構遭入侵後被 OpenJDK 移除；而 Teku 所使用的 Eclipse Temurin 基礎鏡像在客戶端發佈時尚未包含相應的修復。通過發佈更新的鏡像，Teku 團隊確保了獲取新標籤的運營者將獲得一個信任儲存中已排除受損內容的 Java 運行環境。隨此發佈附帶的公告強調，若預設的主網節點未配置任何 HTTPS URL，則無需採取任何行動。風險僅限於主動連接遠端 HTTPS 端點以進行信標協調、外部簽名、建造者或其他類似服務的配置。
運行較舊 Docker 鏡像（包括標記至 26.10.2 的版本）的運營者，仍會使用信任受影響根證書的運行時環境。更新主機的 Java 安裝不會自動更新現有容器內的運行時環境，因此需要拉取新的鏡像。Teku 進一步指出，Java 26 已結束生命週期，不會提供修補版本；仍使用該版本的運營者應遷移至目前的長期支援版本 Java 25，並使用對應的 -jdk25 鏡像標籤。因此，此版本發布結合了根證書移除與運行時版本管理建議。由於此變更僅限於 Docker 鏡像的信任儲存庫，共識行為與驗證者金鑰處理保持不變。此更新被視為建議性的安全措施，而非緊急共識升級，反映受影響配置的範圍有限。
Besu 26.10.2 應用並行證書信任調整
由同一生態系統維護的執行層客戶端 Besu 於 2026 年 10 月 26 日發布了 26.10.2 版本，在其 Docker 鏡像中實施了相同的根證書移除。並行的發布時間和相同的證書目標表明，基於 Java 的以太坊客戶端堆棧對 eMudhra 事件具有協調的認知。執行客戶端與共識客戶端及外部服務互動以進行負載構建和交易包含；它們維持的任何 HTTPS 通信路徑都受與 Teku 相同的證書驗證規則影響。通過從其鏡像中移除對受損權威的信任，Besu 為依賴其 Docker 發行版的運營者關閉了相應的攻擊面。
與 Teku 類似，Besu 的更新不會自動修復使用獨立管理的 Java 執行環境的獨立二進位安裝。此類運營者必須獨立檢查並更新其本地信任儲存或 Java 版本。雙客戶端發布表明，以太坊節點軟體堆疊的共識層和執行層均認識到對 Java 證書處理的共同依賴。由於許多生產驗證者同時運行如 Teku 的共識客戶端和如 Besu 的執行客戶端，同步更新可降低節點對中間憑證的殘留信任風險。發布前未報告任何利用案例，表明實際可用窗口期有限，但協調修補仍代表對以太坊協議之外已知密碼學失敗的審慎防禦措施。
Java 預設未檢查撤銷機制造成长期暴露
一個關鍵的技術細節是，Java 證書驗證預設不會檢查撤銷狀態。即使 eMudhra 已撤銷中間證書，且主要平台已封鎖它們，任何其信任儲存中仍包含相應根證書或中間證書的 Java 運行時，仍會繼續接受鏈接到這些權威的證書。OpenJDK 發布了修復程式，首先封鎖了受損的中間證書，隨後移除了四個相關的根證書。然而，攜帶舊版 Temurin 或 OpenJDK 版本的 Docker 鏡像並不會自動接收這些修復。平台層級的撤銷與嵌入式 Java 運行時行為之間的差距，正是需要進行客戶端特定鏡像更新的原因。
對於以太坊運營者而言，此影響屬於運營層面而非理論層面。配置包含遠端服務 HTTPS 端點的驗證者，會繼承其所使用 Java 運行時的信任決策。若該運行時未更新或未替換為已修補的映像，客戶端仍會接受偽造的憑證。在精心設計的設定中，相互 TLS 或固定憑證可降低風險，但許多生產環境配置仍依賴標準信任儲存庫驗證。因此，Teku 和 Besu 的發佈實質提醒了容器化節點軟體擁有獨立於主機系統的憑證儲存庫。將 Docker 映像視為不透明黑箱的運營者，可能直到外部事件迫使更新時才注意到此細節。此事件也突顯了在運行基於 Java 的以太坊客戶端時，監控上游 Java 安全通告的重要性。
預設主網設定避開了主要攻擊面
Teku 的建議明確指出，配置中不包含任何 HTTPS URL 的預設主網節點不受影響，無需採取任何行動。大多數在本地運行共識客戶端和執行客戶端、且未使用遠端簽名或遠端信標端點的驗證者，均屬於此類。Ethereum 所使用的點對點發現和 gossip 協議不依賴 eMudhra 證書授權機構，進一步保護了標準設置。風險主要集中在那些為操作便利、簽名密鑰的地理分佈或與第三方區塊建構服務整合而主動引入外部 HTTPS 依賴的運營者。這一區分對於評估整體網路影響至關重要。由於大多數主網驗證者使用的配置從未連接到有漏洞的證書鏈，即使在修補程式發布前，理論上的攻擊面也保持有限。
儘管如此，客戶團隊決定發佈更新的圖片，保護了使用遠端服務的運營者子集，並確保未來的鏡像拉取都從一個強化後的基線開始。透過 HTTPS 下載初始狀態的測試網配置被標記為可能暴露，這表明相同的證書邏輯也適用於主網之外。任何依賴 HTTPS 引導或遠端端點的網路運營者，都應將 2026 年 10 月的版本視為其環境中的強制性更新。預設與非預設配置之間的明確分離，使該公告對大多數驗證者集而言既精確又令人安心。
外部簽名者與遠端信標節點代表最高風險路徑
在 Teku 列舉的各種情境中，外部簽名服務具有較高的嚴重性。這些服務將驗證者的私鑰離線存儲或存儲於專用硬體中，並透過網路連線回應簽名請求。如果攻擊者能透過呈遞偽造的證書來冒充簽名者，驗證者客戶端可能會接受授權操作員從未意圖執行的簽名，包括更改費用接收者設定或啟動退出的簽名。強制執行雙向 TLS 認證的配置可將影響限制為拒絕服務，因為攻擊者無法完成經過認證的握手。在缺乏雙向認證的情況下，獲得可用簽名的風險更高。遠端信標節點則帶來相關但不同的問題。
一個將某些協調職責委派給遠端信標端點的驗證者，會信任該端點提供的職責、區塊內容和網路狀態資訊。因此，成功的仿冒行為可能影響驗證者最終提案的區塊，包括嵌入該區塊中的費用接收者位址。區塊建造者和中繼者還通過其他 HTTPS 介面引入了可能注入操縱負載的途徑。在每種情況下，攻擊者都必須先取得允許攔截的網路位置，然後再提供一個未修補的 Java 執行環境所接受的憑證。這些要求的組合縮小了現實中潛在攻擊者的範圍，但成功的提案所導致的費用重定向所帶來的潛在收益，使防禦性修補成為必要。維護外部簽名者或遠端基礎設施的操作者，應優先更新客戶端並審查這些鏈接上的認證機制。
運行獨立二進制文件的操作員需分別履行 Java 更新義務
使用 Docker 的用戶可透過拉取新的 Teku 26.10.3 或 Besu 26.10.2 鏡像來修復問題。以獨立二進位檔或套件安裝客戶端的運營者，則依賴主機系統上的 Java 運行時環境。對於這些安裝方式，客戶端發行版本身不會更改主機的信任儲存庫。因此，運營者必須確認其安裝的 Java 版本已包含 OpenJDK 的修補程式，以移除受損的根憑證，或手動調整憑證儲存庫。Teku 特別警告，Java 26 已停止支援，不會提供修補版本；為繼續獲得支援與安全更新，必須遷移至 Java 25。這種容器化與裸機部署之間的差異在以太坊基礎設施中很常見，並為節點運營者提供了實際的檢查清單項目。
Java 版本的清單、信任儲存內容的確認，以及確認沒有任何 HTTPS 端點仍指向不受信任的服務，構成補丁後的基本安全措施。由於底層加密失敗發生在以太坊之外，任何運營者可能使用的其他基於 Java 的工具都需遵循相同的 Java 更新要求。因此，客戶端公告不僅是針對 Teku 和 Besu 的具體修復，也促使運營者審計其整個系統的證書處理。若未處理主機 Java 環境，即使客戶端軟體已更新，理論上的攻擊路徑仍會保持開放。
在補丁發布前，未發生已確認的利用行為
Teku 建議與同期報導均指出，尚未觀察到任何針對此漏洞的利用行為。未發現已知事件的情況，與成功攻擊所需的狹窄條件一致：未修補的 Java 執行環境、與外部服務的 HTTPS 連線，以及攻擊者能夠攔截該特定連線並提供偽造證書。大多數驗證節點從未同時滿足前兩個條件。10 月 17 日公開披露可恢復密鑰與客戶端映像發布之間的短暫間隔，進一步壓縮了實際攻擊窗口。
未觀察到攻擊並不會降低這些修補程式的價值。與憑證相關的漏洞可能長期處於休眠狀態，直到出現機會主義的攻擊者為止。透過從 Docker 信任儲存中移除受損的根憑證，客戶團隊消除了對更新操作員的偽造憑證的接受。這一事件也生動展示了外部加密失敗如何與以太坊質押基礎設施產生交集，促使操作員審視自身的依賴關係圖。未來涉及憑證授權機構或語言執行時的事件，很可能會引發類似的客戶端層級回應，強化快速、針對性緩解的模式。
證書安全風險如何延伸至區塊鏈網路
eMudhra 事件並非以太坊獨有；任何依賴標準 TLS 信任儲存的軟體，都會繼承其所信任的證書頒發機構的安全狀態。嵌入 Java、Go 或其他語言運行時的區塊鏈客戶端，必須以與應對共識變更相同的謹慎態度追蹤上游證書更新。Java 預設配置省略吊銷檢查的事實，放大了影響，迫使客戶端團隊自行發佈信任儲存修改。其他在容器內打包長期運行時的生態系統，也面臨類似的風險。
對於 Ethereum 質押 社群而言，實際的教訓是，運營安全不僅限於密鑰管理與客戶端版本控制，還需涵蓋每個網路元件的憑證驗證行為。採用遠端簽名、分散式信標節點或第三方中繼的運營者，會引入額外的信任邊界，這些邊界必須被監控。透過 CA 撤銷、平台封鎖和客戶端映像更新，成功遏制此特定漏洞，顯示出當每一層防禦都能迅速響應時，分層防禦是有效的。持續保持客戶端多樣性仍具有重要價值，因為不同實現可能以不同速度發現或緩解外部依賴，降低單一憑證失敗同時影響整個驗證者集的機率。
驗證者基礎設施近期的並行問題凸顯持續警惕的必要性
2026 年 10 月的證書補丁是在其他與驗證者相關的安全關注背景下到來的。此前有關質押服務基礎設施和費用接收方處理的披露，已促使大規模自願退出並加強了對獎勵流動的監控。此外，開發人員在即將推出的 Glamsterdam 升級草案規則中解決了一個存款路由問題，該問題可能在某些公鑰碰撞情況下導致質押存款被錯誤分配；該修復在額外審查後被合併至共識規範中。這些並發事件表明，即使核心協議持續演進，驗證者經濟學和運營安全仍是持續受到關注的領域。
該證書漏洞的根源不同；它源自外部CA，而非以太坊規範或客戶端共識漏洞，但卻觸及了相同的經濟層面：提案者所獲手續費與獎勵的去向。因此，客戶端的快速響應符合一項更廣泛的模式，即將任何現實的獎勵轉移路徑視為高優先事項。維護多元化客戶端設置、監控鏈上手續費接收地址，並保持共識與執行軟體為最新版本的運營者，更能有效應對此類外部衝擊。eMudhra 案例中未出現損失，進一步證明及時修補和配置紀律仍是有效的防禦手段。
以太坊節點運營者在十月發佈後需要做什麼
驗證者和節點運營者應確認在使用 Docker 時運行的是 Teku 26.10.3 或更高版本，以及 Besu 26.10.2 或更高版本；若使用二進制文件，則應使用等效的已修補 Java 運行時環境。應審查所有 HTTPS 端點；如需使用此類端點，建議採用雙向 TLS 或證書釘紮以提供額外保護。仍在使用 Java 26 的運營者必須遷移至受支援的版本。即使在信任儲存更新後，監控所提議區塊中非預期的費用接收地址，仍是一種低成本的偵測方法。由於底層金鑰在被發現前的很長一段時間內均可恢復，因此對歷史連接和證書接受日誌進行一次性審計，可提供額外保障，儘管目前尚未報告任何利用案例。
這些步驟對大多數運營商而言是漸進式的，而非轉變性的。大多數主網驗證者從未接觸過有漏洞的證書鏈，因此僅將此事件視為提醒，應保持容器映像和 Java 執行環境為最新版本。對於那些確實依賴外部服務的用戶，這些修補程式關閉了一條具體且此前被低估的途徑。持續關注上游證書和執行環境的公告，將降低未來類似外部故障再次造成類似漏洞窗口的可能性。Teku 和 Besu 團隊的協同行動不僅提供了即時修復方案，也為處理與以太坊客戶端軟體交織的下一次外部加密事件提供了範例。
常見問題
eMudhra 證書到底哪裡出了問題？
eMudhra 運營的八個中間證書授權機構，在 2025 年的密鑰儀式中生成的私鑰隨機性不足。這些密鑰可從公眾證書中恢復，任何獲取這些密鑰的人都能發出欺詐性證書，而軟體仍會信任這些授權機構接受這些證書。其中六個中間機構用於 TLS，兩個用於代碼簽名。eMudhra 於 2026 年 10 月 17 日發現後撤銷了這些證書，主要平台隨後封鎖了相關內容。
是否有任何驗證者因為這個漏洞而實際損失了 ETH 奖勵？
尚未報告任何已確認的利用或獎勵損失。客戶警示與當時的報導均指出，未觀察到任何攻擊。所需條件的組合——未修補的 Java 執行環境加上與易受攻擊的外部服務建立的活動 HTTPS 連線——限制了實際的攻擊面，而迅速發布已修補的 Docker 鏡像進一步降低了風險。
預設的以太坊主網節點是否受影響？
包含無 HTTPS 連結的預設主網 Teku 設定不受影響，無需採取任何行動。相同原則亦適用於類似的 Besu 設置。風險僅限於那些主動為信標節點、外部簽名器、建造者或類似服務配置遠端 HTTPS 端點的運營者。
憑證被撤銷後，為何 Java 運行時仍存在漏洞？
Java 預設不會檢查憑證撤銷狀態。即使中間憑證已被瀏覽器和作業系統撤銷並封鎖，只要 Java 安裝中仍包含對應的根憑證在其信任儲存中，就會繼續接受鏈接到這些根憑證的憑證。因此，攜帶舊版執行環境的客戶端 Docker 映像需要明確移除根憑證。
使用 Docker 鏡像的運營者應該做什麼？
拉取並運行 Teku 26.10.3 或更高版本，以及 Besu 26.10.2 或更高版本。這些映像已不再信任受損的根證書。僅更新主機系統不會更新現有容器內的運行環境；需要使用新的映像。
那麼，運行客戶端作為獨立二進制文件的運營商呢？
這些操作員必須更新或重新配置主機的 Java 安裝，以納入 OpenJDK 的修補程式，移除受影響的根憑證。Java 26 已停止支援，將不會提供修補版本；建議遷移至 Java 25。客戶端軟體的更新本身不會更改主機的信任儲存庫。
免責聲明：此為一般市場資訊，可能來自第三方、商業或贊助來源，僅供參考及教育用途，不構成財務或投資建議、要約、招攬或保證。我們對其準確性、完整性、可靠性及任何由此產生的損失不承擔責任。投資/交易存在風險；過往表現並不保證未來結果。用戶應自行研究、謹慎判斷，並承擔全部責任。如需進一步詳情，請參閱 KuCoin 的 Terms of Use 及 Risk Disclosure。
免責聲明: 本頁面經由 AI 技術翻譯，旨在方便您的閱讀。欲獲取最準確資訊，請以原始英文版本為準。