Rogue Core-Geth Release Incident Report

We strongly recommend running etclabscore/core-geth Argos (v1.12.23), and DO NOT switch to ethereumclassic/core-geth v1.13.0.

On 2026-09-14 a repository called ethereumclassic/core-geth published a release tagged v1.13.0, the rogue release. Shortly after, the @ETC_Network account on X posted it as an “Ethereum Classic security update” and told node operators to migrate. The same text appeared on the Ethereum Classic community feed on CoinMarketCap, and mining pools received a notice by email from an ethereumclassic.com address, which is not the community’s domain.

Neither the community website at ethereumclassic.org nor the long-standing core-geth codebase at etclabscore/core-geth had been updated. The rogue release was not announced to any of the existing maintainers of core-geth, and was not reviewed by them. It was pushed through social channels that bypassed the community’s public posting process.

In the confusion, a small number of pool operator nodes briefly switched to the rogue release. They have since moved back to running etclabscore/core-geth.

The maintained client, which is run by a supermajority of node operators, lives at etclabscore/core-geth and its current release, as of 2026-09-16, is Argos (v1.12.23). We strongly recommend that node operators do not switch to ethereumclassic/core-geth. Nothing in the rogue release fixes a vulnerability in that version, as is claimed.

We analysed the rogue fork’s commit history, its release notes and its documentation. This post is what we found, with links so you can check it yourself.

The Incident

First, what actually happened.

Context on Core-Geth

Core-geth is the Go client most of the Ethereum Classic network runs. It has lived at etclabscore/core-geth since February 2020, has over 300 stars and close to 200 forks, and its commit history runs from the original ETC Labs authors through to Diego, who maintains it today. Every core-geth release the network has ever run came from there, and presently over 90% of ETC nodes reachable on etcnodes.org run this codebase.

Releases there carry Greek names alongside the version number. This year so far there have been three. Aegis (v1.12.21) on 2026-03-18 backported p2p handshake hardening from go-ethereum. Hermes (v1.12.22) followed ten days later with the remaining crypto backports. Argos (v1.12.23) on 2026-08-14 backported go-ethereum’s delayed p2p message decoding. Argos is the current release as of 2026-09-16, and it is what we recommend node operators run if they are using core-geth. Other clients are available, including Nethermind, Besu and Getc.

The Rogue Release

Within 56 hours, 96 commits adding 13,422 lines and removing 3,977 were pushed straight to the main branch of a fork, with no review by anyone, and then publicly announced as the new version of Ethereum Classic’s main client.

The rogue fork, ethereumclassic/core-geth, was forked from etclabscore on 2024-12-21, under the community GitHub org that also holds the ECIPs and the website. Nobody proposed it, nobody reviewed it, and no maintainer of the client was asked. One person with rights on the org, and no track record of contributing to any blockchain client, clicked fork, and from that moment a repository with the project’s name on it existed for anyone to point at. For twenty months it was dormant, until last weekend.

Last weekend, the following occurred. Here is the timeline in UTC, taken from the tags and the commit log.

96 commits and 17,399 lines of code modified in a weekend, seven release candidates, a stable tag, and an announcement the next morning. There is no reviewer and no pull request behind any of those commits, which were pushed directly to main. One person wrote the changes, one person tagged them, and the network was told to install them the next morning. That much change with no time for anyone else to read it is a problem in any software. In a client that decides which chain a node follows and which peers it talks to, and that was being pushed at the operators who run the hashrate, it is a potential catastrophe.

The closest analogy we can find is an amateur window cleaner deciding, mid-flight, to replace the cockpit windows of an airliner. Passengers on board, no engineer consulted, no ground check, and a cheerful announcement over the intercom that the old windows were unsafe. Ethereum Classic carries over a billion dollars of other people’s value, that this amateur window cleaner was happy to gamble.

@ETC_Network is not a personal account. It is one of the two community X accounts, and for four years every post to it has gone through a public pull request that anyone can read before and after it is sent. This one did not. It was posted directly by whoever holds the password, and by then the public process had already been locked out.

Crisis Averted

2Miners is one of the largest Ethereum Classic pools by hashrate, and its status page lists every one of its ETC nodes with the client version each reports. At 12:09 UTC on 2026-09-15, four of those nodes were reporting the rogue CoreGeth v1.13.0. Eleven hours later, at 23:35 UTC, every one of them was back on v1.12.23, Argos.

All the large ETC mining pools are now safely running Argos. That is the crisis averted. It was averted because operators verified the information with the maintainers before they trusted it, and we commend their professionalism.

However, it appears some nodes are still on the rogue release. At 07:33 UTC on 2026-09-15, etcnodes.org showed eleven nodes on the rogue v1.13.0.

View full size

By 2026-09-16 the count was ten. Three of those are the rogue fork’s own bootnodes, on the exact IP addresses commit eb0cb35a hard-codes. If one of the others is yours, switch back to Argos. If you are a mining pool or node operator and want to talk to a human about any of this, write to [email protected].

The Code

Now let’s look at what the rogue release contains, and why the security claims do not hold.

Thirteen Thousand Lines in Three Days

Here is what the rogue fork’s own commit statistics say about the volume of change, counted with the GitHub API across the 203 commits that separate it from etclabscore master.

For comparison, Argos, the maintained client’s August release, was two pull requests by Diego with multiple human reviews.

Here is the commit log of the rogue fork’s main branch as GitHub shows it, six screens of it, from the top on 2026-09-15 back to the last commits that came from etclabscore in 2024. Read them left to right, top to bottom. One committer, all the way down.

Think about what it would take to review the weekend’s diff. Over four thousand lines of new Go in an Ethereum client, touching the ethash cache, the p2p discovery layer, the chain configuration and the flag handling. Consensus software has one property that makes it different from every other kind. A bug does not crash your process, it forks you off the network, and if enough hashrate is running the same bug the network forks with you. That is why client teams run changes through a review, then a testnet, then a release candidate that operators run for weeks, then a stable tag. Mordor exists for this. So does the ECIP process.

None of that happened here. Nobody reviewed anything. The release candidates lasted hours each, which is not long enough for a Mordor node to finish syncing, let alone hit an edge case. And the consensus test fixtures the build checks itself against were moved, in the same weekend, to a repository the same author controls.

Then the whole thing was announced to mining pools as an urgent security update. Pools run the hashrate that decides which chain is Ethereum Classic. Asking them to move to a client with an untested chain-selection change and a new set of bootnodes, on a Sunday, with no review behind it, put the network at risk.

The Security Claims

The release notes for the rogue v1.13.0 open like this.

Every node running a v1.12.x release should upgrade.

Every v1.12.x release carries unpatched security issues, and one of them was exploited against Ethereum Classic bootnodes in March 2026.

View full size

Look at step one of that banner.

1. Upgrade, and change where you track releases. Releases are cut from ethereumclassic/core-geth. A node tracking the previous repository will not see v1.13.0.

Operators should be extremely skeptical of such requests, and ask themselves why a security fix would require anyone to change which repository they track. Once an operator’s tooling tracks the rogue fork, every release from the original maintainers goes unseen. This is a capture step, dressed as a security step.

It is also the oldest trick in social engineering. Act fast, do not think, do this one thing. A siren emoji, a list of CVEs, a warning that your node is unsafe, and the first instruction is the one that hands over control. The urgency is the bait, and the release feed is the switch.

The rogue release lists seven identifiers it claims are unpatched in etclabscore/core-geth. For the avoidance of doubt, here is each one against the code the maintained client ships, so anyone can verify that the claim is false.

• CVE-2026-22862, RLPx handshake crash from a short ECIES ciphertext. Fixed in Aegis (v1.12.21) by commit 6d4968db. crypto/ecies/ecies.go line 296 rejects any ciphertext shorter than the public key, the MAC and one AES block.
• CVE-2026-26315, ECIES invalid-curve oracle leaking bits of the node key. Fixed in Aegis by commit 34894227, with a regression test added in Hermes (v1.12.22) by 46bba8df. crypto/ecies/ecies.go line 127 rejects any remote public key that is not on the curve before the ECDH step.
• CVE-2026-26314, secp256k1 coordinate outside the field. Fixed in Hermes by commit 0ebf4922. Both curve implementations, crypto/secp256k1/curve.go line 95 and crypto/signature_nocgo.go line 172, refuse a coordinate at or above the field prime before the on-curve check.
• CVE-2025-24883, off-curve public key accepted by UnmarshalPubkey. Fixed in Hermes by commit ae6bad2d. crypto/crypto.go line 181 checks IsOnCurve and returns an error otherwise.
• CVE-2026-26313, memory exhaustion from a crafted p2p message. Mitigated in Hermes by commit 7940b281, and fixed the upstream way in Argos (v1.12.23) by pull request 699, which backports go-ethereum’s delayed message decoding so that no message is materialised before its size and item counts are checked.
• CVE-2026-22868, KZG proof verification denial of service. Not applicable. KZG proofs belong to blob transactions, which exist only from Ethereum’s Cancun upgrade. Ethereum Classic has no Cancun activation and no blob transactions, so there is no proof for a peer to send.
• GraphQL query depth, no CVE assigned. Not a critical bug and not enabled by default. GraphQL starts only with the --graphql flag, for specific application use cases where a private deployment queries its own node under a different trust assumption from the p2p layer. Anyone who can send a deep GraphQL query already has access the operator chose to grant. Nothing in the p2p or consensus path touches it.

Five of the seven were fixed in the maintained client between March and August 2026, by number, and the other two won’t reach Ethereum Classic nodes that are being used in p2p. The rogue fork’s own March 2026 audit document, at docs/audits/2026-03-security-audit.md, knows this. It describes v1.12.21 and v1.12.22 as “CVE-only backports”. That is an admission that the CVEs were patched upstream.

Diego, the maintainer of core-geth, went through what remains of the rogue client diff. There is no exploitable flaw in v1.12.23 that the rogue v1.13.0 fixes. And even if there was one, the way to handle it is to disclose it privately to the maintainers, not to suddenly announce a rival release to mining pools.

What the Rogue Client Shipped

Strip out the version bumps and the regenerated documentation and the “security release” is a handful of behaviour changes to how a node selects its chain, finds its peers and picks its network, plus a move of the code’s own test vectors and dependencies to repositories the same author controls. None of these actually fix a vulnerability in Argos. Bundled along with this supposed security update are the following changes to how core-geth operates:

Re-enabling MESS

Commit a7fd45b8, params/config_classic.go line 83, deletes ECBP1100DeactivateFBlock: big.NewInt(19_250_000) and replaces it with a seventeen-line comment arguing that “it is a client’s to make”. The same commit does the same to Mordor. One deleted line turns MESS back on for every node that installs this release.

The network made this decision the other way, in public, for good reasons. MESS was added in 2020 as a temporary patch on chain selection, when Ethereum’s proof-of-work hashrate dwarfed ETC’s and a rented majority was cheap. That threat left with Ethereum’s move to proof of stake in 2022, and ECIP-1110 turned MESS off at the Spiral block after a month of discussion. The strongest argument in that thread was about exactly the situation we are now in.

We really do not want to only have a subset of nodes running MESS (or worst case would be 50-50) because that risks a permanent chain-split.

Core-geth is the only ETC client that ever implemented MESS. Switching it back on in one client, while Besu, Nethermind and Getc weigh competing chains the normal way, splits the network into two groups that can prefer different forks. That was pushed at miners and pools, which is the worst place for it. A pool is not an observer, it produces the blocks. If the pools run MESS and everyone else does not, the first time two chains compete the pools can keep mining the chain the rest of the network rejects, their miners’ rewards go with it, and with enough hashrate on the MESS side the split does not heal.

Hijacking Peer Discovery

Commit eb0cb35a, params/bootnodes_classic.go line 42, swaps the DNS tree signing key from AJE62Q…, held by the etclabscore maintainers since 2020, to APDLRZ…, and hard-codes three new bootnode IPs. A code comment in the same file admits the three domains “are served by a single DNS account, so separate names are the only redundancy available if one zone breaks; they are not independent providers”. Commit c0b5857 then deletes OldClassicDNSNetwork1 and OldClassicDNSNetwork2, the blockd.info and etcdisco.net trees, and drops them from cmd/utils/flags.go at line 2260. After that a node on this release finds peers only through infrastructure one person runs.

Where those trees come from is a second repository, ethereumclassic/discv4-dns-lists, created under the community org on 2026-08-28 by the same account, again with nobody asked. It publishes the node lists to three domains, ethereumclassic.net, ethclassic.net and ethereumclassic.network, all on one Cloudflare account, and its README concedes that “a single Cloudflare account problem removes every path at once”. The release notes say only that “peer discovery uses this project’s DNS trees”. Neither they nor the migration guide name the repository, the domains, or who holds the signing key. An operator following the upgrade instructions had no way to know their node’s view of the network was being handed to a DNS account they had never heard of.

Redefining the Network Flags

Commit c3b911f, cmd/utils/flags.go lines 169 to 198, changes --mainnet to mean “Ethereum Classic mainnet, the same as —classic”, moves --ethereum, --sepolia and --holesky into the deprecated category with the usage text “refuses to start”, and at line 1236 changes the bootnode selection so that params.ClassicBootnodes is used only when the chain is Classic and nothing otherwise. Running with no flag at all now means Ethereum Classic.

Moving the Test Vectors and Dependencies

Commit 693d8e41, .gitmodules line 8, changes the ETC consensus test fixtures from etclabscore/tests to fukuii-project/archive-reference-material. Commit ed99f029, go.mod lines 184 to 190, adds replace directives that build the OpenRPC modules from the same repository. The fukuii-project org was created in July 2026, and the rogue fork’s own commits are what point its builds there. Fukuii is a new Ethereum Classic client, unrelated to core-geth, which the rogue fork’s README names as core-geth’s successor. The vectors your build validates consensus against now come from the same place as the code.

Requiring a Key Rotation

The migration guide makes rotating your P2P node key a “required step”, citing CVE-2026-26315, which the maintained client fixed in Aegis in March.

The node key is what gives a node its identity on the peer-to-peer network. Its public half is the enode ID that other nodes remember, that pools and exchanges pin in static peer lists, and that discovery trees record. Rotating it makes the node a stranger. Every peer forgets it, every static peering that named it breaks, and the node rebuilds its view of the network from discovery, which on this release means the rogue fork’s bootnodes and DNS trees. The stated reason, a key leak over repeated handshakes, was closed by Aegis in March. A node on Aegis, Hermes or Argos had nothing to rotate for.

The README puts the MESS decision in its own words.

View full size

The Rogue Fork Is Vibe Coded

The rogue fork ships a CLAUDE.md, an AGENTS.md and a .github/copilot-instructions.md, with a table of which model tier to use for “consensus rules, chain configuration, cryptography”. All 27 of the March pull requests end with “Generated with Claude Code”. And no human writes 96 commits to a Go client in a weekend, thirty of them regenerating documentation, with commit messages that close on “Verified rather than assumed” and “Calibrated by”.

The problem is not with agentic tooling itself. We clearly use these tools ourselves, especially for non-critical applications. The problem is that no experienced human reviewer was in the loop before large changes were pushed straight to production on a network holding over a billion dollars of value. An agent will produce plausible, well-commented, confidently described changes to consensus rules at any speed you ask for, and it will not know which of them forks a network. There are proper ways to use an LLM on code like this, and to validate what it produces, but every one of them costs time and attention to detail.

The Donation Address

The README ends by asking pools, exchanges, ETF issuers, hardware manufacturers and large holders to fund the work, via [email protected] or by sending to this address “on any EVM chain”.

We looked it up on ETC. It is not a multisig or a contract. It is an ordinary account with about four ETC in it and over 2,500 outgoing transactions, which is what an everyday wallet looks like, not a project treasury. The commit that added it, 71c90b93 on 2026-09-14, also added a copy button.

Think about what that address is attached to. Core-geth is go-ethereum, thirteen years of work by hundreds of people, plus multi-geth, plus six years of ETC Labs, ETCDEV and Cooperative engineers making it follow this chain, plus the maintainers who have kept it patched through 2026. The rogue fork adds a few days of one person’s vibe-coded commits on top, most of them documentation. Then it puts the Ethereum Classic name on the front, a warning banner telling operators they are unsafe, and a wallet address at the bottom with a copy button, addressed to the pools, exchanges and hardware makers who fund the network.

Picture a national park. It belongs to nobody and everybody. The trails, the bridges and the signposts were built and repaired over decades by volunteers and rangers, most of whom nobody remembers by name. Now picture someone who turns up one weekend, nails a new sign over the entrance in the park’s own lettering, tells visitors the old paths are dangerous, and sets out a collection box with their personal bank details on it. The park was never theirs to sell, and we will leave it to the reader to decide what to call a collection box like that.

The same README declares the rogue fork “the canonical home of Core-Geth from here on”, calls v1.13 “the last Core-Geth release line”, and says core-geth will be sunset in favour of Fukuii, a Scala client from the same people. It also states that a Wyoming company called Ethereum Classic DAO LLC “succeeds the ETC Cooperative”, a company of which the same person is one of the two organizing members.

What Now

And finally, what operators should run and what org maintainers should change.

What to Do

We strongly recommend not to run v1.13.0 from ethereumclassic/core-geth. We recommend you continue to run the client that has been, and continues to be, maintained at etclabscore/core-geth. The current release is Argos (v1.12.23), also available as the etclabscore/core-geth image on Docker Hub. Check the org name in any link before you download. If a “security update” for ETC arrives by email or social post rather than from the maintainers, ask the maintainers, and please stay vigilant.

If you already moved a node to the rogue v1.13.0, move it back. Chain data is compatible in both directions. Restore your previous node key if you rotated it on the rogue fork’s instructions, and check that your MESS setting is what you intend.

We also recommend not running only core-geth. Ethereum Classic has several clients, including Nethermind, Besu and Getc, and a network where most of the hashrate runs one client has a single point of failure whatever that client is.

A Request to the Organization Maintainers

To the admins and maintainers of the ethereumclassic GitHub org. You hold this namespace in trust for a network that has no other owner, and you are the curators of its community assets, with a responsibility to make sure they are not abused and do not put the network at risk. This weekend a repository under the org was used to get large mining operators to run unreviewed, vibe-coded consensus software with MESS enabled. Serious damage to the network, including a chain split, was thankfully avoided, and we trust you understand the implications of what could have been.

This incident has already damaged the project’s reputation and put it at risk technically, and it has shown that there are gaps in whatever the current system is. Ultimately it is the org admins’ responsibility to decide who gets what access to which repositories, and a serious review and inquiry needs to take place so that this cannot happen again.

We request the following:

• Tighten up the org’s security. Today a single member can create a repository under ethereumclassic, name it whatever they like, and publish releases from it with no review by anyone. That is how, in one weekend, a fork with one contributor and a new bootnodes repo got presented to pools as the official client. Creating a repository under the org should require a proposal and a review, the same way an ECIP or a website change does. Repositories that ship software should name their maintainers, protect their default branch and require review before merge.
• Better still, the ethereumclassic org should not be used for any additional code repositories and should stay purely informational. A neutral gathering place for the community to organise information, which is what the ECIPs, the website and the community calls already are. Every client should live under its own maintainers’ org for the reasons we set out in the website pull request in March. This incident is the perfect example of why we made that argument, and why we are thankful that pull request was not pushed through.
• Remove or archive the ethereumclassic/core-geth repository, and put a banner in its README warning that it is not some kind of official or seriously maintained client. If someone wants to maintain a fork of core-geth, this should be encouraged, but they should do it under their own org and earn users on the record, the way every other client does. Allowing one person, with zero discussion, to crown themselves the maintainer of the official core-geth repository is the antithesis of Ethereum Classic. At the very least there needs to be branch protection and some kind of process for deciding what goes into that repository, and it should not be blessed as official.
• Consider removing or revoking access for individuals who have shown a reckless disregard for the security of the network. Org membership means being granted rights, and with them responsibilities, and this weekend showed what happens when the rights are exercised and the responsibilities are not. When one rogue actor breaks social norms multiple times without any consequence, it simply encourages this kind of behaviour. This is the same individual who edited and hid critical comments on the Olympia ECIP discussion, who blocked the ECIP-1120 pull request for weeks under a self-declared “compliance lock” until other maintainers approved it, and who rewrote the titles and text of the Ethereum Classic community call archives going back to 2023, and pushed the rewrite to production the same day.
• Be responsive and responsible. Org maintainers need to respond to incidents like this one, stay in touch with what is actually happening on the network, and maintain a neutral, fair-handed approach to moderation. Unfortunately, some of the existing org admins have been unresponsive as of late, and that makes it difficult to respond to important incidents like this one in a timely manner. Again, these roles come with responsibilities, and we do not think it is unfair to expect them to be upheld as the project continues.

We do not think these requests are controversial or unreasonable, and we hope they are duly considered by all ethereumclassic GitHub organization admins.

No Official Anything

Every page on ethereumclassic.org carries a disclaimer at the bottom.

The content on this website is user-generated and solely for informational purposes. Do not interpret any content as an endorsement of any product or service. There’s “no official anything” in Ethereum Classic. Always do your own research, and remember: don’t trust, verify!

That is more than a disclaimer, and the site explains why. Like Bitcoin, ETC has no official developers, maintainers or leaders. No official logo, website, conference or client. Nobody can claim to represent the network, so nothing official can be captured or taken down, and there is no seat at the top to take.

The flip side is that there’s no way to prevent anyone from claiming it, and every so often someone does. A “canonical home of Core-Geth”. An audit signed “Ethereum Classic Core Developers”. A security update from ethereumclassic.com. A proposal to make a protocol treasury redirect funds to Ethereum Classic DAO LLC. Each is a claim to be the official thing in a project that has none, and each falls apart the moment you check who is behind it. These kinds of claims should be recognised as the social attacks they are; an attempt to trick you into thinking someone represents something they cannot.

The etclabscore repository is not the official core-geth either. But it is the one with an active maintainer who has experience developing ETC clients, six years of public history, and releases that a supermajority of the network has decided to run. That record is the only kind of authority there is in ETCistan, and it is the kind you can verify yourself.

Whenever someone uses the name “Ethereum Classic”, think carefully about what they are claiming. Do they phrase things in a way that makes it seem like they represent a decentralized project that has no leaders? Does this claim even make sense?

That is why we are called Classix. No claims, no games, just a rabid desire for cybernetic justice.

…and remember folks: Don’t Trust, Verify.

---

Incident Record

Some operators who run ETC infrastructure are regulated entities with incident-management obligations of their own. For them, and for the record, here is the incident in that shape.

• What happened. An unreviewed client release under the community’s GitHub name was announced to node operators and mining pools as an urgent security update, on 2026-09-14 and 2026-09-15, through the community X account, the CoinMarketCap community feed and direct email.
• Possible cause. The ethereumclassic GitHub org allowed a single member to create a repository carrying the project’s name and publish releases from it with no review, and the credentials for the community X account were held outside the public posting process.
• Immediate impact. A small number of pool nodes ran the release for under twelve hours. No blocks were lost, no reorg occurred, no funds were affected, and no service went down. Ten nodes, three of them the release’s own bootnodes, still report it.
• Affected systems. The core-geth client, its peer discovery, and the network’s chain-selection settings on any node that installed the release.
• Relevant third parties. GitHub, X, CoinMarketCap, Cloudflare as the DNS provider for the release’s discovery trees, and the mining pools that received the notice.
• Classification. Severity high, impact low. It qualifies as major on the criteria of critical services affected, since the release changed consensus behaviour on the client a supermajority of the network runs, and reputational impact. It does not qualify on transactions affected, duration, data loss or economic impact, all of which were nil.
• Reporting. This post is the initial notification and the intermediate report combined, published within 48 hours of the announcement. This document will be updated if the remaining nodes are accounted for, if the organization maintainers respond, or if anything material changes.
• Root cause and follow-up. Root cause is the absence of review controls on the community org, set out in the section above. The follow-up actions are the five requests to the organization maintainers, and the recommendation that operators run more than one client.