以太坊開發者已解決兩項分別可能危及驗證者存款與區塊獎勵的漏洞：一項涉及薄弱的網站憑證，另一項則存在於該網路即將進行的 Glamsterdam 升級草案規則中。共識客戶端 Teku 與執行客戶端 Besu 各自發布了修補程式以處理此風險。以太坊節點同時運行共識客戶端與執行客戶端，意味著節點堆疊的兩個層級都需要進行同樣的憑證清理。

Teku 於 10 月 27 日發布 26.10.3 版本，一天前 Besu 已於 10 月 26 日推出 26.10.2 版本。根據 Teku 的發布頁面，兩個版本均將受影響的憑證授權機構自用於運行以太坊節點的 Docker 映像中移除。

薄弱憑證金鑰遭揭露

研究人員於 10 月 17 日發現，印度 eMudhra 簽發的八張中繼憑證所依賴的私鑰，攻擊者可從公開資訊推算得出。取得這些金鑰後，攻擊者本可為偽造服務簽發憑證。eMudhra 已撤銷這些憑證，但部分 Java 安裝環境仍持續信任它們，因為 Java 預設不檢查憑證撤銷狀態。Teku 與 Besu 均以 Java 撰寫，這正是此弱點波及以太坊節點運作的原因。

同一週，Google 也預覽了一套加密貨幣託管安全系統，設計上是將私鑰分散於不同的環境中。

驗證者費用如何可能被轉走

此憑證缺陷之所以重要，是因為驗證者依賴與外部服務的連線。能夠攔截此類連線的攻擊者，可以冒充連線另一端的服務。Teku 警告，與遠端節點之間的偽造連線，可能導致區塊費用被支付至攻擊者控制的地址。在受影響的設定中，外部簽名服務構成額外風險，因為攻擊者可能取得會將獎勵轉走的簽名。

「主網上的預設 Teku 節點不受影響，無需採取任何行動，」Teku 表示。該客戶端團隊未通報任何已知的利用案例。

Glamsterdam 存款規則獲得修正

在另一項工作中，研究人員 avsetsin 發現存款路由錯誤後，開發者修訂了 Glamsterdam 草案規則。他們也延後了原定於 10 月 26 日進行的 Hoodi 測試網升級。

在先前的草案下，共享同一組公鑰的建構者與驗證者，可能導致質押存款進入建構者的帳戶。Glamsterdam 的設計目標是將區塊建構與驗證分離，而修訂後的提案則按提領憑證對待處理的存款進行排序，以區分驗證者存款與建構者存款。

客戶端團隊最初於 10 月 19 日因缺乏共識而否決該修正。開發者隨後加入測試，並於 10 月 26 日合併修訂後的規則。

節點營運者面臨不同的後續步驟

Glamsterdam 修正已納入以太坊的規格，但軟體團隊仍需加以實作。Glamsterdam 先前已在 Sepolia 測試網上運行，而 Hoodi 則等待新的啟用日期。

在 Docker 之外運行 Teku 或 Besu 的營運者必須另行更新 Java。此憑證風險涵蓋自以太坊 gas 費用中支付的款項，例如支付給驗證者的優先費用，而非一般使用者的錢包餘額。Teku 建議使用已不再受支援的 Java 26 的使用者改用 Java 25。

憑證修補程式已解決受影響的 Docker 映像，而 Glamsterdam 修正則有待以太坊客戶端生態系統的全面採用。