Teku 和 Besu 在 eMudhra 事件後更新了它們各自的 Docker 鏜像，因為薄弱的證書密鑰給連接到外部服務的軟件帶來了風險，其中也包括一些以太坊驗證者的部署。

• Teku 26.10.3 和 Besu 26.10.2 在 Docker 镜像中移除了受影響的證書信任，原因是 eMudhra 事件。
• Teku 表示，默认主網節點不受影響，實際暴露程度取決於 HTTPS 連接以及運營者使用的 Java 運行時。
• 披露的風險涉及被冒充的服務和驗證者操作，Teku的通知中沒有報告被利用的情況。

對於運營者來說，目前最直接的问题是：在連接到其他服務時，他們的軟件是否會接受偽造的證書。答案取決於所使用的連接方式和 Java 的安裝情況，因此客戶端更新並不意味着每個驗證者都面臨相同的風險。

Teku 和 Besu 更新 Docker 镜像

以太坊客戶端團隊已發布更新，以修復一個源自區塊鏈之外的證書問題。相關變更涉及軟體如何判斷遠端服務是否真實。

Teku 在 26.10.3 和 Besu 在 26.10.2 从它们的 Docker 镜像中移除了對受影響證書根的信任。此次發布是因為發現了與證書頒發機構 eMudhra 相關的弱密鑰。

對於驗證者運營者而言，問題在於攻擊者會假冒軟件所連接的服務。根據該服務的角色不同，偽造回應可能會打亂職責的分配，或影響某些區塊費用的支付去向。

但這並不意味着每個以太坊驗證者都處於風險之中。Teku 的安全通知稱，默認情況下主網節點不受影響，而且目前也沒有報告任何被利用的情況。

差異在於安裝方式。使用外部 HTTPS 服務的運營者，需要檢查那些在完全本地化組件部署中未必存在的連接。

這些更新適用於特定的安裝環境。補丁後的 Docker 鏜像包含了容器內打包的運行時修改，而從歸檔文件安裝的軟件則可能使用運營者另外提供的 Java。

這起事件影響的是驗證者周邊的基礎設施，而以太坊的共識規則並未改變。

證書問題為何會演變成安全風險？

證書幫助軟體判斷自己是否已連接到預期的服務。受信任的證書發行機構會為伺服器證書所對應的身份提供背書。

這種機制在 HTTPS 網站中很常見，但在不透過瀏覽器進行通訊的應用中同樣適用。後端服務也可能依賴於這些身份驗證。

證書頒發機構可能會在受信任的根證書之下使用中間證書。與這些中間證書相關的私鑰必須保持安全，因為它們可以被用來頒發更多的證書。

在這起事件中，問題並不只是有人拿到了服務器的普通登錄信息。受影響的中介密鑰可以從已經公開的信息中恢復出來。

Go 安全團隊的說明稱，這一弱點允許在微秒級別恢復私鑰。其描述還指出，攻擊者隨後可以為自己並不控制的域名創建證書。

如果某個容易受到攻擊的應用程式認為該證書最終仍可以追溯到它所信任的機構，就有可能接受它。這樣一來，偽造身份就有可能通過原本用來拒絕冒名頂替者的檢查。

不過，攻擊者仍然需要某種方式來截斷或重新導向受害者的連線。弱密鑰並不會自動讓他們出現在每個用戶與每臺伺服器之間。

這一條件縮小了攻擊發生的方式，但並不能讓證書失效變得無害。只要軟體將冒充者當作真實端點，網路攔截就會變得更加危險。

Kudelski Security 的研究審視了受影響的證書層級。問題在於，該軟件可能會接受由攻擊者能夠複現的密鑰簽發的證書。

eMudhra 將弱密鑰歸因於處理錯誤

eMudhra 的事件聲明稱，一名研究人員在10月17日報告了8個弱中間密鑰。該公司在次日撤銷了這8個密鑰。

公司表示，這些中間證書是在2025年4月30日的一場密鑰儀式中生成的。按照公司的說法，存在缺陷的wrap和unwrap步驟在原本的強密鑰之外又生成了弱副本。

公司稱使用了經過認證的硬體安全模組。其解釋將故障歸因於周邊流程中的某一步，而非歸因於缺乏這類設備。

公司還表示，其中7個中間證書從未用於生產環境，剩餘的1個也尚未簽發證書。公司稱此次事件沒有造成基礎設施被入侵或數據泄露。

這些說法解釋了 eMudhra 對其內部運作的描述。但軟體供應商仍需應對另一種可能性：其他方可能利用可恢復的密鑰。

證書系統不能只依賴原始運營方承諾不再簽發任何內容。一旦其他人也能複現某個簽名密鑰，這種保證就不再能控制所有可能被創建的證書。

因此，應對措施已經超出了生成密鑰的那家公司的範圍。瀏覽器製造商、操作系統供應商和編程語言團隊都需要考慮他們用戶的軟件將會接受什麼。

這些修復會通過不同的更新傳遞給用戶。瀏覽器可能會收到阻斷名單，而另一個獨立的 Java 應用程式仍可能繼續使用舊的受信任證書集。

弱密鑰和接受該密鑰的應用程式是同一問題的兩個不同部分。撤銷證書解決的是機構記錄層面的問題，而客戶端還需要一種可靠的方式來識別自己應該拒絕受影響的信任路徑。

外部服務給驗證者帶來不同風險

以太坊節點由承擔不同職責的軟件組成。以太坊客戶端文檔區分了執行客戶端和共識客戶端：前者處理交易執行和狀態，後者遵循權益證明共識。

驗證者軟件則增加了提議區塊及對鏈進行證明的職責。運營者可以在本地運行這些組件，也可以透過外部服務來連接其中的一部分。

Teku 是共識客戶端，Besu 是執行客戶端。兩者都使用 Java，這也是為何運行時的證書信任與它們的發布相關的原因。

本地機器以外的服務會為這種安排增加一道身份驗證。軟體需要確認回應請求的端點就是預期中的提供者。

例如，運營者可能會使用遠端簽名服務，而非將簽名操作保留在同一個進程中。也有些人可能會依賴外部端點來提供數據或區塊構建服務。

冒充者能造成多大的損害，取決於該服務被允許從事什麼。只接收監控數據的服務，與參與簽名決策的信息服務，風險並不相同。

網路路徑同樣重要。穿越公共基礎設施的連接，與僅限同一主機或受嚴格控制的私有網絡（VPC）中的組件相比，被截獲的機會不同。

私有網路無法讓所有故障都完全不會發生，但它可以減少攻擊者獲得干擾流量所需機會。

因此，僅憑客戶端名稱並無法判斷是否已暴露。相同的軟件可以部署在使用不同端點、信任庫和訪問控制的环境中。

真正需要回答的问题是：哪條連線通過了受影響的路徑來接收證書。一旦明確這一點，運營者就能評估被冒充的服務在驗證者運作中本應擁有多大的權限。

為何 Docker 鏜像與歸檔安裝不同？

Docker 镜像會將應用程序及其運行所需的環境一起打包，其中可能包括 Java 運行時以及該運行時所信任的證書。

更新主機上的 Java，並不會自動替換現有鏡像中的 Java。容器仍可能繼續使用自己打包的檔案。

這就是客戶端發布說明會特別提到 Docker 更改的原因。 Teku 的說明稱，其 Eclipse Temurin 基礎鏡像當時尚未包含相關移除內容，因此客戶端鏡像直接進行了修改。

Besu 的發布說明同樣表示，其證書移除適用於 Docker 鏜像，並明確要求歸檔安裝用戶檢查自己提供的 Java 發行版。

歸檔安裝會將這項責任留給運營者。以太坊客戶端可能已經更新，但其單獨的運行時仍可能包含舊的證書儲存。

反過來，在維護過程中也會出現類似的區別。替換主機運行時會影響使用該運行時的進程，但不會影響使用不同 Java 路徑的安裝。

Oracle 的事件建議用戶更新受影響的運行時，或遵循其文檔中給出的替代方案。它還要求重新啟動正在運行的實例，并分別考慮每個獨立安裝。

這使得正在運行的進程比下載到的更新更加重要。伺服器可以包含已經打補丁的文件，但舊進程仍會繼續運行，直到被替換或重新啟動。

自定證書儲存方式又增加了另一種變化。某個組織可能使用的證書庫是為其自身服務所維護的，而不仅仅是 Java 預設提供的證書庫。

實際任務是找出客戶端真正使用了什麼。安裝方式、運行時位置和信任配置共同決定了已發布的修復是否已經到達了需要它的那條連接。

不同應用中吊销檢查的差異

撤銷意味著該證書不應再被接受。但這並不能保證每個應用在建立連接之前都會檢查最新的撤銷信息。

不同應用程式獲得這些資訊的方式也各不相同。有些會查詢線上服務，有些則使用供應商提供的阻斷名單，還有些主要依賴於本地信任庫中的證書。

Go 团队的回應說明了為何運行時供應商可能需要直接介入。該團隊在10月19日發布了緊急安全補丁，並表示在收到通知後大約7.5小時內就提供了修復版本。

此動作阻斷了使用相關 Go 驗證行為的應用所涉及的受影響證書路徑。 Java 使用者則需要透過自己的運行時和信任設定來獲得保護。

Teku 的通知稱，Java 預設不會檢查是否已經撤銷。這也是為何即使 eMudhra 已經撤銷了這些中間證書，仍有必要在本地移除信任的原因。

根證書的移除和中介證書的阻斷也可能在不同的層面上發生作用。前者是拒絕某一條特定的受損路徑，而後者則可以拒絕通往被移除的根證書的更廣泛的證書鏈。

正確的實現屬於供應商和維護應用的組織。若臨時採取一種禁用身份驗證的辦法，只會移除保護，而非解決信任問題。

合法服務也可能需要調整。如果它們的證書依賴於客戶端現在拒絕的路徑，那麼服務方就必須提供可接受的替代方案，而不是指望用戶恢復不安全的信任。

這也解釋了為何一個證書事件可能會持續數天。發現問題可能是即時的，但保護措施會通過瀏覽器、打包應用程式和私有基礎設施的不同發布與維護流程逐步到位。

對於驗證者運營者來說，關鍵結果在於相關連接是否已經拒絕了不受信任的身份。軟件生態系統中其他地方的撤銷公告，並不能證明其節點進程已經達到了這一結果。

獎勵和驗證者的質押是否以相同的方式暴露？

驗證者的質押、簽名職責和費用支付彼此相關，但它們受到不同機制的約束。影響其中一項的問題，不應該被自動描述為對所有這些內容的控制。

以太坊質押文件說明，驗證者通過履行職責獲得獎勵，並會因離線或可證明的不當行為而受到懲罰。簽名權限和提現權限在系統中扮演不同角色。

證書密鑰屬於用於連接的身份系統。它不是驗證者的私人簽名密鑰，也不會直接泄露管理已質押 ETH 提現的憑證。

不過，被冒充的服務仍可能影響驗證者的行為。其影響取決於該服務處理哪些請求或回應，以及還保留了哪些額外檢查。

區塊提議包含執行相關支付的花費接收方。若某條路徑能夠修改提議或配置，就可能產生後果，而無需控制整個質押。

簽名服務又帶來了另一組問題，因為它涉及對授權驗證者行為的監控。其自身的保護措施，包括對請求的限制以及防止衝突簽名的保障，都會影響攻擊者能夠做到什麼程度。

服務中斷導致的職責遺漏也是可能的後果之一。即便沒有成功轉移任何支付，攻擊者只要阻止正確的響應，也有可能減少獎勵。

這些結果的財務影響並不相同。錯過提議區塊的機會、普通的離線懲罰和減輕處罰，不能混為一談。

客戶端公告描述的是在受影響的配置下可能出現的後果，並沒有證明每個運營者都遭遇了這些後果，也沒有證明有相應數量的 ETH 被盜。

對於使用質押服務商的持有者來說，真正相關的是服務商的實際部署。管理了多少 ETH，並不能說明其運營者使用了哪些遠程服務或證書庫。

驗證者也依賴於以太坊以外的軟件

以太坊網路規則只是運營者所依賴的一部分。硬體、運行時環境、託管服務、配置設定以及外部服務都會影響驗證者能否正確履行職責。

證書發行機構位於以太坊協議之外，但當驗證者軟件依賴它來識別服務時，它的故障就會變得相關。單憑這一點，就足以將一個通用的互聯網安全問題帶入質押基礎設施中。

客戶端的多樣性仍然具有價值，因為不同的實現可以減少對單一代碼庫的依賴。但這並不意味着每個依賴項都是獨立的。

兩個客戶端可以使用相同的編程語言運行時。不同的運營商也可能使用同一家託管服務供應商、簽名服務或區塊構建基礎設施。

這些共享組件會在以太坊軟體本身的不同情況下，形成共同的暴露面。因此，要理解部署情況，不能只看客戶端品牌的數量。

外包也會帶來權衡。專用簽名服務可能改善密鑰保護方式，但同時也會讓與該服務的認證連接變得更加重要。

在本地運行也有其自身的維護要求。將組件放置在同一台機器上可以減少部分網絡風險，但運營者仍需管理軟體更新以及對該臺機器的訪問。

這起事件並不會自動提供一種在所有情況下都最安全的架構。它所說明的是，必須理解並維護每一條連接周邊的責任。

這種區別對普通的 ETH 使用者來說也很重要。節點基礎設施中的證書補丁，並不意味著每個錢包都必須轉移資金，也不意味著以太坊賬戶餘額發生了變化。

相關行動屬於受影響的軟件運營者。他們才有能力識別所涉及的運行時、端點和信任設定，然後將供應商的相關指導應用到正在建立這些連接的系統上。

運營者需要應用並檢查更新

這些發布為運營者提供了從受支持的 Docker 鏜像中移除受影響的信任路徑的方法。而歸檔用戶則需要根據各自 Java 供應商的指導，處理單獨的運行時工作。

補丁可用只是流程的第一步。更新後的環境還需要真正運行，並保持預期配置和服務正常工作。

對於服務提供方來說，由最近被拒絕的證書所引發的中斷，可能需要在端點更換證書。在恢復服務時應該保留身份驗證，而不是繞過它。

後續披露可能會進一步細化影響。運營者或許會識別出某些接受了受影響證書鏈的配置，或報告涉及特定服務的事件。

就目前而言，Teku的通知報告尚未被利用，並且區分了默認主網的使用與受到影響的外部連接。這是描述當前以太坊暴露面的最清晰依據。

受影響的運營商有理由進行更新。任何財務損失取決於攻擊者偽裝了哪項服務、是否截斷了流量，以及驗證者允許該服務進行什麼操作。

需要關注什麼

• 客戶端更新：關注 Teku 和 Besu 的發布，並確認已運行修補後的版本。
• Java 警告：請參閱每個安裝所使用的 Java 運行時和證書庫的供應商說明。
• 外部連結：審查指向遠端簽名、數據和區塊構建服務的 HTTPS 鏐鏈。
• 安全通知：請留意客戶端團隊和 Java 供應商發布的確認攻擊或進一步說明。

常見問題

eMudhra 事件是什麼？

這起事件涉及與證書發行機構 eMudhra 的中間證書相關的弱私鑰。研究人員發現，這些密鑰可以從公開信息中恢復，從而可能讓其他人創造自己並不控制的域名證書。信任受影響證書路徑的軟件可能會接受這種偽造的身份。攻擊者仍然需要某種方式來截斷或重定向連接，才能冒充目標服務。

以太坊的共識機制失敗了嗎？

沒有。報告中的問題涉及軟體如何檢查外部服務的身份，而非以太坊在區塊鏈上達成的共識規則。客戶端更新改變的是受影響軟體環境中的證書信任。某些驗證者部署如果遭遇外部服務被冒充，仍可能面臨運營風險。這種可能性取決於連接和服務角色，並不意味著以太坊共識規則被破壞。

哪些客戶端被更新了？

Teku 在 26.10.3 和 Besu 在 26.10.2 修改了他们的 Docker 镜像，以移除受影响的證書信任。Teku 是共識客戶端，Besu 是執行客戶端，兩者都使用 Java。安裝方式非常重要，因為該變更適用於這些鏡像中提供的環境。安裝客戶端歸檔並自行提供 Java 運行時的運營者，需要單獨查看該運行時的指導。

所有驗證者都會受到影響嗎？

不會。Teku 的通知稱，默認情況下主網節點不受影響。風險取決於某個部署是否進行了相關的外部 HTTPS 連接，以及其證書檢查是否接受受影響的信任路徑。不同運營者可以在不同的服務、Java 版本和證書庫下運行同一客戶端。因此，客戶端名稱或質押的 ETH 数量，並不能說明某個特定驗證者是否暴露。

Docker 更新能覆蓋所有安裝方式嗎？

不可以。補丁後的 Docker 鏜像會更新該鏡像內打包的環境，但歸檔安裝可能會使用運營商提供的另一個 Java。其他容器或服務也可能有自己獨立的運行時環境。運營商需要識別正在運行的進程所使用的安裝方式，並遵循其供應商的說明。伺服器上已經打過補丁的文件，並無法保護仍在舊環境中運行的進程。

是否已確認被利用？

在本文所述的時間點，Teku 的通知中並未報告有任何被利用的情況。相關的披露描述的是一個弱點及其可能的後果，而非證明攻擊者已經將其用於驗證者。在討論損失時，這一區別非常重要。存在一條冒充服務的可能途徑，並不等於簽名職責被操縱、費用支付被轉移或 ETH 被盜。

驗證者存款會自動曝光嗎？

不會。證書簽名密鑰與驗證者簽名密鑰不同，也與控制提現的憑證不同。恢復受影響的證書密鑰，並不會自動泄露提取 ETH 所需的密鑰。被冒充的服務仍可能打亂職責或影響驗證者使用的信息，具體取決於部署方式。應針對該服務評估可能的後果，而不是將其視為對整個存款的自動訪問。

運營者應該如何做？

運營者應遵循相關的 Teku 或 Besu 發布說明，以及其 Java 發行版的指導。需要識別每個受影響進程所使用的運行時和證書庫，包括容器內提供的部分。應用建議更新後，應確認更新後的服務正在運行，且所需的連接仍能正常工作。為了恢復失敗的連接而禁用證書檢查，會移除這些檢查本應提供的保護。