在數個礦池節點短暫採用 Core Geth v1.13.0 版本後又恢復使用維護中的 Argos 客戶端，Ethereum Classic 節點營運商已被敦促避免使用這個有爭議的版本。
Classix 在一份 9 月 16 日的事件報告中指出，ethereumclassic/core-geth 儲存庫於 9 月 14 日發布了 v1.13.0，隨後 @ETC_Network 帳戶將其宣傳為 Ethereum Classic 的安全更新，並告知節點營運商進行遷移。類似的訊息也出現在 CoinMarketCap 上，同時礦池也收到了來自 ethereumclassic.com 電子郵件地址的郵件。
報告將此發布描述為一個流氓版本，因為現有的 Core Geth 維護者並未審查它，且維護中的 etclabscore/core-geth 儲存庫也未發布此更新。Classix 建議營運商繼續使用 Argos v1.12.23，這是自 2020 年以來一直維護 Core Geth 的儲存庫的當前版本。
在該版本發布前的幾天內，這個有爭議版本的開發速度加快。根據 Classix 的說法，在 56 小時內，有 96 次提交（包含 13,422 行新增程式碼和 3,977 行刪除程式碼）直接被推送到分支的主幹，沒有經過拉取請求或外部審查。
ethereumclassic/core-geth 儲存庫本身是在 2024 年 12 月從 etclabscore/core-geth 分叉出來的。活動在 2026 年 9 月 12 日增加，當時標記了 v1.13.0-rc1。隨後發布了六個更多的候選版本，直到 v1.13.0 在 9 月 14 日世界標準時間 15:06 被標記為穩定版。@ETC_Network 帳戶在第二天早上發布了遷移請求。
該軟體在營運商撤銷遷移之前，曾到達 Ethereum Classic 的部分挖礦基礎設施。根據 Classix 引用的節點狀態數據，9 月 15 日世界標準時間 12:09，四個 2Miners 節點正在運行 CoreGeth v1.13.0。到世界標準時間 23:35，這四個節點都已恢復使用 Argos v1.12.23。其他列出的礦池仍停留在 1.12 系列版本。
一些單獨的節點繼續運行這個有爭議的軟體。Etcnodes.org 顯示，9 月 15 日世界標準時間 07:33 有 11 個 v1.13.0 節點，到 9 月 16 日數量降至 10 個。根據報告，其中三個剩餘節點與新客戶端中硬編碼的啟動節點 IP 地址相符。
Classix 表示，在事件期間，沒有區塊丟失，沒有鏈重組發生，沒有資金受到影響，也沒有服務中斷。報告將此事件歸類為高嚴重性但低影響，因為該軟體改變了共識行為，但未產生任何記錄的經濟或交易損失。
Ethereum Classic 之前曾面臨鏈重組問題。正如 crypto.news 在其關於 Ethereum Classic 多數攻擊的報導中曾提及，ETC 在 2020 年 8 月遭受了三次多數攻擊，其中包括涉及數千個區塊的重組。
v1.13.0 版本告知營運商，所有運行 v1.12.x 的節點都應升級，並聲稱該系列中的每個版本都包含未修補的安全問題，包括據稱在 3 月份用於攻擊 Ethereum Classic 啟動節點的漏洞。
Classix 在審查了該版本引用的七個安全問題後，對這一描述提出了質疑。其中五個已在 3 月至 8 月期間的維護 Core Geth 版本中得到解決，而另外兩個則不影響 Ethereum Classic 的點對點路徑，報告稱。
Classix 表示，CVE-2026-22862 和 CVE-2026-26315 是在 Aegis v1.12.21 中修復的漏洞。Hermes v1.12.22 隨後解決了其他加密問題，而 Argos v1.12.23 整合了來自 go-ethereum 的延遲點對點訊息解碼，以解決 CVE-2026-26313。
另一個列出的問題 CVE-2026-22868 涉及 KZG 證明驗證。Classix 表示它不適用於 Ethereum Classic，因為 KZG 證明與透過 Ethereum 的 Cancun 升級引入的 blob 交易相關，而 ETC 尚未啟用此功能。報告指出，一個單獨的 GraphQL 查詢深度問題不屬於點對點或共識路徑，並且需要手動啟用 GraphQL。
Classix 表示，Core Geth 維護者 Diego López León 審查了其餘差異，並未發現 Argos 中有 v1.13.0 糾正的任何可利用缺陷。
除了其安全聲明之外，v1.13.0 還改變了參與節點選擇鏈和發現同行的方式。
其中一項修改是重新啟用了修改指數主觀評分（Modified Exponential Subjective Scoring, MESS），方法是移除了在區塊 19,250,000 時停用它的配置。Ethereum Classic 在 2020 年引入 MESS 作為防止鏈重組的保護措施，但在 Ethereum 從工作量證明轉向權益證明後，透過 ECIP-1110 將其停用。
Classix 警告說，如果只有 Core Geth 節點使用 MESS，不同的共識客戶端可能會表現出不同的行為。根據報告，Besu、Nethermind 和 Getc 並未實施該機制。
歷史性的重組對於 ETC 來說仍然是一個特別相關的問題。crypto.news 對區塊鏈重組歷史的回顧描述了在工作量證明網絡上，礦工共識和競爭鏈歷史如何決定重組的結果。
這個有爭議的客戶端也改變了節點發現基礎設施。一個提交替換了由 etclabscore 貢獻者自 2020 年以來維護的 DNS 樹簽名密鑰，並硬編碼了三個新的啟動節點 IP 地址。隨後移除了兩個較舊的發現樹，blockd.info 和 etcdisco.net。
根據報告，三個替代域名都託管在同一個 Cloudflare 帳戶上，而儲存庫承認，影響單一帳戶的問題可能會移除所有三條路徑。Classix 表示，遵循遷移指令的營運商並未被告知誰控制了新的簽名密鑰。
遷移指南另外指示營運商輪換其 P2P 節點密鑰，理由是 CVE-2026-26315。Classix 表示 Aegis 已於 3 月修復了底層問題。輪換密鑰會改變節點的網絡身份，並迫使其透過發現基礎設施重建對等連接。
Classix 建議營運商避免使用 ethereumclassic/core-geth v1.13.0，並繼續運行 etclabscore/core-geth Argos v1.12.23。已遷移的營運商被告知要移回，如果密鑰已輪換則恢復其之前的節點密鑰，並檢查其 MESS 配置。
報告指出，Ethereum Classic 營運商應考慮運行不同的客戶端，而不是將網絡算力集中在 Core Geth 上。Nethermind、Besu 和 Getc 仍然是可用的替代方案。
客戶端多樣性已成為區塊鏈網絡中一個重複出現的安全考量。例如，以太坊開發繼續在部署前測試多個執行和共識實作的升級。最近的 Glamsterdam 測試網準備工作包括在測試發現共識和執行實作錯誤後，又進行了一次私人開發網測試，以應對計畫中的 Sepolia 啟用。
Classix 要求 ethereumclassic GitHub 組織的管理員加強儲存庫控制，要求在建立新儲存庫之前提出提案和審查，保護預設分支，並為分發軟體的儲存庫指定維護者。它另外要求移除或歸檔 ethereumclassic/core-geth，或附帶一個警告，解釋它不是官方客戶端。
根據報告中引用的項目網站免責聲明，Ethereum Classic 本身不指定官方開發者、維護者、網站或客戶端。Classix 表示，維護中的 etclabscore 儲存庫是從其六年公開歷史、活躍維護和 ETC 節點中的採用中獲得其地位的。
本報告旨在作為初步通知和中期事件報告。Classix 表示，如果剩餘節點得到驗證、組織維護者做出回應或出現其他重要進展，它將更新此文件。
