Betreiber von Ethereum-Classic-Knoten wurden aufgefordert, die umstrittene Core Geth v1.13.0-Version zu vermeiden, nachdem mehrere Mining-Pool-Knoten die Software kurzzeitig übernommen hatten, bevor sie zum gepflegten Argos-Client zurückkehrten.
Zusammenfassung
- Mehrere Mining-Pool-Knoten von Ethereum Classic wechselten kurzzeitig zur umstrittenen Core Geth v1.13.0-Version, bevor sie zu Argos v1.12.23 zurückkehrten.
- Classix gab an, dass 96 Commits innerhalb von 56 Stunden ohne externe Überprüfung eingereicht wurden, bevor v1.13.0 veröffentlicht und als Sicherheitsupdate beworben wurde.
- Der umstrittene Client reaktivierte MESS und änderte die Knoten-Erkennungsinfrastruktur, während Classix erklärte, dass keine Blöcke, Gelder oder Dienste von dem Vorfall betroffen waren.
- Classix forderte Betreiber auf, v1.13.0 zu vermeiden, und bat die GitHub-Administratoren von Ethereum Classic, die Repository- und Überprüfungskontrollen zu verschärfen.
Classix erklärte in einem Vorfallbericht vom 16. September, dass das Repository ethereumclassic/core-geth am 14. September v1.13.0 veröffentlichte, bevor der @ETC_Network-Account es als Ethereum-Classic-Sicherheitsupdate bewarb und Knotenbetreiber zur Migration aufforderte. Ähnliche Nachrichten erschienen auf CoinMarketCap, während Mining-Pools E-Mails von einer ethereumclassic.com-Adresse erhielten.
Der Bericht beschrieb die Veröffentlichung als rogue Version, weil die bestehenden Core Geth-Maintainer sie nicht überprüft hatten und das gepflegte etclabscore/core-geth-Repository das Update nicht herausgegeben hatte. Classix empfahl Betreibern, weiterhin Argos v1.12.23 zu verwenden, die aktuelle Version aus dem Repository, das Core Geth seit 2020 pflegt.
Rogue Core Geth-Veröffentlichung erreichte einige ETC-Mining-Knoten
Die Entwicklung der umstrittenen Version beschleunigte sich in den Tagen vor ihrer Veröffentlichung. Laut Classix wurden 96 Commits mit 13.422 hinzugefügten Zeilen und 3.977 gelöschten Zeilen innerhalb von 56 Stunden direkt in den Hauptzweig des Forks eingereicht, ohne Pull-Requests oder externe Überprüfung.
Das Repository ethereumclassic/core-geth selbst war im Dezember 2024 von etclabscore/core-geth geforkt worden. Die Aktivität nahm am 12. September 2026 zu, als v1.13.0-rc1 getaggt wurde. Sechs weitere Release-Kandidaten folgten, bevor v1.13.0 am 14. September um 15:06 UTC als stabil gekennzeichnet wurde. Der @ETC_Network-Account veröffentlichte die Migrationsaufforderung am folgenden Morgen.
Die Software erreichte einen Teil der Mining-Infrastruktur von Ethereum Classic, bevor Betreiber die Migration rückgängig machten. Vier 2Miners-Knoten liefen am 15. September um 12:09 UTC mit CoreGeth v1.13.0, laut Knotenstatusdaten, die von Classix zitiert wurden. Bis 23:35 UTC waren alle vier zu Argos v1.12.23 zurückgekehrt. Andere aufgeführte Mining-Pools blieben auf Versionen der 1.12-Serie.
Einige einzelne Knoten liefen weiterhin mit der umstrittenen Software. Etcnodes.org zeigte am 15. September um 07:33 UTC 11 v1.13.0-Knoten, wobei die Zahl bis zum 16. September auf 10 sank. Drei der verbleibenden Knoten stimmten mit Bootnode-IP-Adressen überein, die fest im neuen Client codiert waren, laut dem Bericht.
Während des Vorfalls gingen keine Blöcke verloren, es kam zu keinen Chain-Reorganisations, keine Gelder waren betroffen und es wurde keine Dienstunterbrechung verzeichnet, so Classix. Der Bericht stufte das Ereignis als hohe Schwere, aber geringe Auswirkung ein, da die Software das Konsensverhalten änderte, aber keine aufgezeichneten wirtschaftlichen oder Transaktionsverluste verursachte.
Ethereum Classic war bereits früher mit Chain-Reorganisations konfrontiert. Wie crypto.news zuvor in seiner Berichterstattung über Ethereum Classic Majority Attacks berichtete, erlitt ETC im August 2020 drei Majority-Angriffe, darunter Reorganisations mit Tausenden von Blöcken.
Classix bestreitet Sicherheitsbehauptungen von v1.13.0
Die v1.13.0-Veröffentlichung teilte Betreibern mit, dass jeder Knoten, der v1.12.x ausführt, aktualisieren sollte, und behauptete, dass jede Version dieser Serie ungepatchte Sicherheitsprobleme enthielt, darunter eine Schwachstelle, die angeblich im März gegen Ethereum Classic-Bootnodes ausgenutzt wurde.
Classix stellte diese Beschreibung nach Überprüfung von sieben in der Veröffentlichung zitierten Sicherheitsproblemen in Frage. Fünf waren bereits in gepflegten Core Geth-Veröffentlichungen zwischen März und August behoben worden, während die anderen zwei den Peer-to-Peer-Pfad von Ethereum Classic nicht betrafen, laut dem Bericht.
CVE-2026-22862 und CVE-2026-26315 gehörten zu den Schwachstellen, die laut Classix in Aegis v1.12.21 behoben wurden. Hermes v1.12.22 adressierte anschließend andere kryptografische Probleme, während Argos v1.12.23 eine verzögerte Peer-to-Peer-Nachrichtendekodierung von go-ethereum integrierte, um CVE-2026-26313 zu adressieren.
Ein weiteres aufgeführtes Problem, CVE-2026-22868, betraf die KZG-Proof-Verifizierung. Classix erklärte, dass es nicht auf Ethereum Classic zutreffe, da KZG-Proofs mit Blob-Transaktionen verbunden seien, die durch Ethereums Cancun-Upgrade eingeführt wurden, welches ETC nicht aktiviert hat. Der Bericht gab an, dass ein separates GraphQL-Abfragetiefenproblem nicht Teil des Peer-to-Peer- oder Konsenspfads sei und GraphQL manuell aktiviert werden müsse.
Classix erklärte, dass der Core-Geth-Maintainer Diego López León die verbleibenden Unterschiede überprüft und keinen ausnutzbaren Fehler in Argos gefunden habe, den v1.13.0 korrigiert hätte.
Core-Geth-Änderungen umfassten MESS und neue Bootnodes
Über seine Sicherheitsbehauptungen hinaus änderte v1.13.0 die Art und Weise, wie teilnehmende Nodes Chains auswählen und Peers entdecken konnten.
Eine Änderung reaktivierte Modified Exponential Subjective Scoring, oder MESS, indem die Konfiguration entfernt wurde, die es bei Block 19.250.000 deaktivierte. Ethereum Classic führte MESS im Jahr 2020 als Schutz gegen Chain-Reorganisationen ein, bevor es durch ECIP-1110 deaktiviert wurde, nachdem Ethereum von Proof of Work auf Proof of Stake umgestellt hatte.
Classix warnte, dass verschiedene Konsens-Clients unterschiedlich reagieren könnten, wenn nur Core-Geth-Nodes MESS verwendeten. Besu, Nethermind und Getc implementieren den Mechanismus laut dem Bericht nicht.
Historische Reorganisationen bleiben ein besonders relevantes Problem für ETC. Eine crypto.news-Überprüfung der Geschichte der Blockchain-Reorganisationen beschrieb, wie Miner-Konsens und konkurrierende Chain-Historien das Ergebnis von Reorganisationen in Proof-of-Work-Netzwerken bestimmen können.
Der umstrittene Client änderte auch die Node-Discovery-Infrastruktur. Ein Commit ersetzte einen DNS-Baum-Signaturschlüssel, der seit 2020 von etclabscore-Mitwirkenden gepflegt wurde, und hardcodierte drei neue Bootnode-IP-Adressen. Zwei ältere Discovery-Bäume, blockd.info und etcdisco.net, wurden anschließend entfernt.
Drei Ersatzdomains wurden laut dem Bericht über dasselbe Cloudflare-Konto gehostet, während das Repository einräumte, dass ein Problem, das das einzelne Konto betrifft, alle drei Pfade entfernen könnte. Betreiber, die den Migrationsanweisungen folgten, wurden laut Classix nicht darüber informiert, wer den neuen Signaturschlüssel kontrollierte.
Der Migrationsleitfaden wies Betreiber separat an, ihre P2P-Node-Schlüssel zu rotieren, unter Berufung auf CVE-2026-26315. Classix erklärte, dass Aegis das zugrunde liegende Problem bereits im März behoben habe. Das Rotieren eines Schlüssels ändert die Netzwerkidentität eines Nodes und zwingt ihn, Peer-Verbindungen über die Discovery-Infrastruktur neu aufzubauen.
Ethereum-Classic-Betreiber aufgefordert, zu Argos zurückzukehren
Classix empfahl Betreibern, ethereumclassic/core-geth v1.13.0 zu vermeiden und weiterhin etclabscore/core-geth Argos v1.12.23 auszuführen. Betreiber, die bereits migriert hatten, wurden angewiesen, zurückzukehren, ihren vorherigen Node-Schlüssel wiederherzustellen, falls er rotiert worden war, und ihre MESS-Konfiguration zu überprüfen.
Der Bericht erklärte, dass Ethereum-Classic-Betreiber in Betracht ziehen sollten, verschiedene Clients auszuführen, anstatt Netzwerk-Hashpower auf Core Geth zu konzentrieren. Nethermind, Besu und Getc bleiben verfügbare Alternativen.
Client-Vielfalt ist zu einer wiederkehrenden Sicherheitsüberlegung in Blockchain-Netzwerken geworden. Die Ethereum-Entwicklung beispielsweise testet Upgrades weiterhin über mehrere Ausführungs- und Konsensimplementierungen hinweg vor der Bereitstellung. Jüngste Glamsterdam-Testnet-Vorbereitungen umfassten ein weiteres privates Devnet, nachdem Tests Konsens- und Ausführungsimplementierungsfehler vor der geplanten Sepolia-Aktivierung aufgedeckt hatten.
Classix bat die Administratoren der ethereumclassic-GitHub-Organisation, die Repository-Kontrollen zu verschärfen, Vorschläge und Überprüfungen zu verlangen, bevor neue Repositories erstellt werden, Standard-Branches zu schützen und Maintainer für Repositories zu benennen, die Software verteilen. Es wurde separat darum gebeten, ethereumclassic/core-geth zu entfernen oder zu archivieren oder mit einer Warnung zu versehen, die erklärt, dass es kein offizieller Client ist.
Ethereum Classic selbst benennt laut dem im Bericht zitierten Haftungsausschluss der Projektwebsite keinen offiziellen Entwickler, Maintainer, keine offizielle Website oder keinen offiziellen Client. Classix erklärte, dass das gepflegte etclabscore-Repository seinen Status stattdessen aus seiner sechsjährigen öffentlichen Geschichte, aktiven Wartung und Akzeptanz unter ETC-Nodes ableitet.
Der Bericht soll sowohl als erste Benachrichtigung als auch als vorläufiger Vorfallbericht dienen. Classix erklärte, dass es das Dokument aktualisieren werde, wenn die verbleibenden Nodes verifiziert werden, Organisations-Maintainer antworten oder andere wesentliche Entwicklungen auftreten.
