簡而言之
- Teku 26.10.3 和 Besu 26.10.2 在受損的中間金鑰暴露部分基於 HTTPS 的驗證器設定於仿冒風險後，移除了與 eMudhra 相關的憑證根信任。
- 預設的 Teku 主網節點未受影響，且尚未報告任何遭利用的情況，風險取決於驗證者是否透過 HTTPS 連接到外部服務。
- Docker 使用者應更新客戶端映像，而獨立運營者則需單獨修補 Java；使用 Java 26 的使用者需遷移至支援的 Java 25 版本。
Teku 和 Besu 在 eMudhra 證書授權機構密鑰遭竊後，釋出安全更新，以解決以太坊節點設定暴露於偽造 HTTPS 連線的風險。Teku 的發行說明 推薦使用版本 26.10.3，該版本從 Docker 鏡像中移除了對四個受影響的證書根的信賴；而 Besu 則釋出了版本 26.10.2。這些更新針對軟體分發層的證書信賴問題，而非以太坊共識規則的缺陷。預設的 Teku 主網節點未受影響，使此事件與 Ethereum 協議的漏洞有所區別。
受損的憑證金鑰造成仿冒風險
研究人員發現，八個 eMudhra 中間證書授權機構的私鑰可被恢復，因為它們是使用不足的隨機性生成的。儘管這些證書已被撤銷，但 Java 預設不檢查撤銷狀態，導致執行環境仍可能接受偽造的證書。因此，在易受攻擊的配置下，位於節點與 HTTPS 服務之間的攻擊者可冒充該端點。這一事件強調了 以太坊客戶端多樣性與運營安全 超越共識代碼的重要性。
風險最高的情境涉及驗證者透過 HTTPS 連接到外部服務。偽造的端點可能操縱區塊建構資訊、重定向費用接收者，或透過假冒的外部簽署者獲取簽名。Teku 表示，攻擊者可導致使用遠端信標節點的驗證者客戶端提議一個將費用支付給攻擊者地址的區塊。此風險取決於網路位置和遠端服務配置，而非僅僅是運行 Teku 或 Besu。目前尚未報告任何利用案例。
Teku 26.10.3 從 Docker 鏡像中移除了對 emSign ECC Root CA G3、emSign Root CA G1、emSign Root CA G2 和 AAA Certificate Services 的信任。Besu 的更新採用了相同的方法。直接運行二進制文件的運營者必須單獨更新 Java，因為客戶端升級不會替換主機運行時的證書存儲。因此，Docker 和獨立部署需要不同的修復路徑。在 Ethereum 驗證者基礎設施事件 暴露了協議外依賴如何影響質押運營後，這一區分變得至關重要。
Java 26 造成了一個問題，因為它已達到生命週期終點，將不再獲得所需的修補程式版本，因此受影響的運營商需要遷移至 Java 25。點對點以太坊網路未被暴露，因為它不依賴這些證書頒發機構。這些修復措施降低了第三方信任儲存庫的風險，但並未修復主網上的實際漏洞，也未更改以太坊的協議。此事件繼承了其他安全工作，包括 Glamsterdam 充幣路由修正，突顯了驗證者安全如何依賴協議代碼和支援基礎設施。