v1.13.0: the record behind the release¶

An article published on 2026-09-16, the Rogue Core-Geth Release Incident Report, tells node operators and mining pools not to run v1.13.0, to move back any node already on it, and to restore the previous node key if they rotated it on this project’s instructions. It claims that nothing in v1.13.0 fixes a vulnerability in v1.12.23. That claim is false, and the article’s advice would leave nodes less secure than the release it warns against. The security fixes in v1.13.0 were reported privately first and made public nearly six months before it shipped.

This page sets out the record: commit metadata, pull requests, release files, advisory records and vulnerability databases. Every answer links to the record it rests on, so it can be checked without trusting this page. Where the article is accurate, this page says so.

The article is published by Classix (classix-dev on GitHub, @classix_dev on X), which credits Istora Mandiri (IstoraMandiri on GitHub) and Diego López León (diega on GitHub) as its authors. Classix is a 2026 Hong Kong company. Its classix.dev domain and its classix-dev GitHub organization were both created on 31 March 2026, and the site’s earliest post is dated 11 May 2026. Its introduction of 9 September 2026, a week before the article, names the same two people as its founders and makes two claims about itself: that of the Cooperative’s closure, “Classix is picking up the torch”, and that Diego López León is “currently the only core maintainer of the Ethereum Classic clients”. Both are the company’s own descriptions of itself, and neither matches what the ETC Cooperative has published. The Cooperative’s own 2024 roadmap names the Ethereum Classic community GitHub repository as where Core-Geth should move, a member of its board has been proposing exactly that on the website since March 2026, and the board has communicated its intent to archive etclabscore/core-geth. v1.13.0 was developed and released from this repository.

On this page: At a glance · Where core-geth is maintained · What the article recommends · The fixes were disclosed first · Since the release · What has happened since the article · When the work was done · What v1.13.0 fixes that v1.12.23 does not · Review · Test fixtures · Peer discovery · Node key rotation · MESS · Check a release yourself · Do not trust this page. Verify it.

At a glance¶

Where core-geth is maintained¶

Core-geth is a public good, and the ethereumclassic organization is where Ethereum Classic keeps its public goods: the ECIPs, the website, the community call archives and ethereumclassic/core-geth.

• ETC Labs developed core-geth until it left the Ethereum Classic ecosystem in 2021.
• The ETC Cooperative maintained it from 2022 through 2024, then entered maintenance mode. Its 2024 retrospective states: “At that time, it will be up to other stakeholders to take on any required maintenance of the ETC client, unless a new plan materializes.” The same report reproduces a conference slide headed “ETC Pathway Proposed by Donald McIntyre”, the Cooperative’s Senior Editor, whose second item reads “Move Core Geth to the Ethereum Classic community repository”. The Cooperative’s published roadmap says the same: Ethereum Classic Pathways, 30 July 2024, lists “Move Core Geth to the Ethereum Classic community GitHub repository: This would restore sovereignty of the community on the node client software.”
• ethereumclassic/core-geth was created in the community organization on 21 December 2024 to carry that maintenance forward, from etclabscore/core-geth at its commit of 16 December, 7ef3ecd7a. The archive-etclabscore-2024-12 branch preserves that point. The repository holds core-geth’s full history up to it, and v1.13.0 includes the v1.12.23 p2p hardening with its original authorship. In March 2026, ethereumclassic.github.io #1678, opened by a member of the Cooperative’s board, proposed pointing the website’s client entry at it, describing the client as “a community asset”. It carries a draft migration announcement written for the website on 2 August 2026, readable on the site’s own deploy preview. Neither has been merged or published, and the website’s client entry still points at the previous project.
• The ETC Cooperative board has communicated its intent to archive etclabscore/core-geth. Future development continues in ethereumclassic/core-geth.

ethereumclassic/core-geth is core-geth’s continuation in the community’s organization, not a rival project. Keeping a reference client in the project’s own organization is common practice, as with Bitcoin Core at bitcoin/bitcoin and go-ethereum at ethereum/go-ethereum.

The ETC Cooperative transition lists the other services moving to the ethereumclassic organization as the Cooperative winds down.

What the article recommends¶

The article tells operators who upgraded to “move it back”, recommends v1.12.23, and says: “Restore your previous node key if you rotated it on the rogue fork’s instructions”.

• Moving back to the published v1.12.23 archives puts the Go standard library advisories back on the node. Each v1.12.23 archive carries 55 to 61, all published before it shipped, and its release build cannot be compiled on a supported Go. Go toolchain lists every one.
• Restoring a rotated node key undoes the rotation that the go-ethereum advisory for CVE-2026-26315 recommends (GHSA-m6j8-rg6r-7mv8). A key that served a v1.12.20 or earlier node should be treated as exposed.

The fixes were disclosed first¶

The security work in v1.13.0 was reported privately to the ETC Cooperative, which owns etclabscore/core-geth, in February and March 2026. It was published as pull requests #10 to #36 on 20 and 21 March 2026, and etclabscore/core-geth cut its emergency releases, v1.12.21 and v1.12.22, on 18 and 28 March. v1.13.0 shipped on 14 September, nearly six months after the fixes were public. The March 2026 audit records the sequence.

Since the release¶

No issue reporting a defect in v1.13.0 has been opened in this repository since it shipped, and operators who moved to it have reported stable nodes. The client was run on Ethereum Classic mainnet and Mordor throughout its development, from February 2026 to the release; the March 2026 audit and dependency and toolchain modernization record that validation.

What has happened since the article¶

The toolchain finding is now being acted on in the other repository. The article, published 16 September 2026, states that “Nothing in the rogue release fixes a vulnerability in that version, as is claimed.” On 17 September 2026, pull request #702 was opened at etclabscore/core-geth, titled “build, go.mod: align the Go toolchain with upstream v1.17.5”. It changes 68 files, including go.mod, go.sum, build/checksums.txt, both Dockerfiles and every workflow, and moves the Go version those workflows request from 1.21 to 1.25.

That is the finding this project reported privately in February and March 2026, published in the March 2026 audit, and shipped in v1.13.0 on 14 September: the v1.12.x line is built by toolchains that are out of support. v1.12.21, v1.12.22 and v1.12.23 each left it unchanged, so operators on that line have carried it since the fixes were made public six months ago, and since v1.12.20 shipped in June 2024 before that.

It is the same three changes this project made. The Go toolchain audit names exactly what stops the v1.12.x source building on a supported Go: fjl/memsize, which reaches into runtime internals through //go:linkname that Go 1.23 tightened; blst v0.3.11, which Go 1.24 rejects for a cgo alias receiver; and the go 1.21 directive itself. Pull request #702 does all three. It removes github.com/fjl/memsize and its debug endpoint, moves blst from v0.3.11 to v0.3.16, and changes the directive to go 1.24.0. It also raises the # version:golang pin in build/checksums.txt from 1.22.1 to 1.25.12, and updates golang.org/x/crypto from v0.17.0 to v0.48.0 along with x/sync, x/sys, x/text, x/time and x/tools.

Those dependency updates had been proposed before, and closed. Dependabot opened them against that repository and they were closed without merging: golang.org/x/net v0.18.0 to v0.36.0 (#671, closed 16 April 2025) and to v0.38.0 (#678), golang.org/x/crypto v0.17.0 to v0.35.0 (#677), and github.com/golang-jwt/jwt/v4 v4.5.0 to v4.5.2 (#674), the last three closed on 14 August 2026, the day v1.12.23 was released. Check where those versions ended up: go.mod at tag v1.12.23 still reads golang.org/x/crypto v0.17.0, golang.org/x/net v0.18.0 and github.com/golang-jwt/jwt/v4 v4.5.0.

Other contributors raised the same build problems and those pull requests were closed too: Go 1.24 compiler support (#683, closed 6 February 2026), the blst upgrade for a failing CI job (#691, closed), and dropping the memsize debug endpoint (#701, closed 17 September 2026).

Three things worth checking rather than taking from this page. Whether that work was already under way before the article is not something this page can know; what it can show is the dates above. Go 1.24 left support on 10 February 2026 and Go 1.25 on 19 August 2026, each when two newer major releases existed, under Go’s published support policy, so a release built from either would still carry standard library advisories, fewer than Go 1.21 carries. And pull request #702 was open, not merged, when this page was written; check its state rather than trusting this sentence.

When the work was done¶

Each commit records when it was written as well as when it was last applied. GitHub shows the first on a commit’s page as the date it was authored. v1.13.0’s history was replayed onto this repository in September 2026, so every commit carries a September commit date and keeps its original author date.

The security fixes and the toolchain upgrade were written in February and March 2026:

They were published as pull requests #10 to #36 on 20 and 21 March 2026, and cross-referenced in etclabscore/core-geth #692 the same weekend. A pull request’s opening date cannot be changed afterwards. The same commits are also in white-b0x/core-geth, where GitHub records them as committed on 25 May 2026, with the same author dates.

The commits dated 12 to 14 September were written on those days. Of the 96 the article counts, 41 are documentation and 31 are release engineering: the release workflows, the build scripts, archive and image publishing, and the release stage. Much of that fixed what the seven release candidates turned up in the release build, such as image attestation, macOS and Windows binary metadata, and publishing the archives from one job. Four commits touch dependencies and three add tests. The remaining 17 change the client: the network defaults, the discovery trees and bootnodes, the MESS flags, chainspec parsing and a medium key derivation tier, which the release report describes, and fixes found running the release candidates, to the Etchash cache and to the Engine API on chains without the merge.

v1.13.0 also carries nine commits authored in etclabscore/core-geth for v1.12.23, the delayed p2p message decoding series, with their authorship unchanged: 68469cb19, 863a59733, b77579985, 92e92dc72, 7a4988919, 14b116bc1, 665b53252, 105dc459d and 62489811f.

What the network is running¶

The article tells operators to move off v1.13.0. Nine nodes were on it. The rest of the network was running a release the audits measure as carrying unpatched advisories, and 158 of those predate the March 2026 emergency patches altogether.

Source: etcnodes.org, 17 September 2026, 524 Core-Geth nodes of 550 on the network. These figures move: https://api.etcnodes.org/peers is the instrument, and the Go toolchain audit and the March 2026 security audit are where each row’s contents are measured.

What v1.13.0 fixes that v1.12.23 does not¶

The six CVEs in the client’s own code are not where the two lines differ most. etclabscore/core-geth backported fixes for four of them in v1.12.21 and v1.12.22, mitigated CVE-2026-26313 in v1.12.22 and hardened p2p message decoding further in v1.12.23, and declared CVE-2026-22868 not applicable to Ethereum Classic. v1.13.0 patches all six. The March 2026 audit and the August 2026 follow-up record which release carried which. The larger difference lies underneath the client’s code.

• The Go standard library. Every v1.12.23 archive was built with go1.21.13 or go1.22.1, and both Go versions had left support before the release shipped. Each archive carries 55 to 61 standard library advisories, all published before v1.12.23, 43 to 47 of them with the vulnerable code present in the binary. v1.13.0 is built with go1.26.8 and carries none. Go toolchain lists every one. Whether the client can reach each one was not assessed.
• Third-party modules. Scanners match 47 advisories against the modules in v1.12.23, 9 of them with the vulnerable code present: in tidwall/gjson, golang-jwt/jwt, gorilla/websocket, consensys/gnark-crypto and golang.org/x/text. 44 are absent from v1.13.0.
• Rebuilding v1.12.23 on a newer Go. Its release build does not compile on any supported Go. Built without memsize and without the KZG build tag, it does, and takes the Go standard library fixes. That build still declares go 1.21, so Go leaves the limits it added for GO-2025-4012 and GO-2026-4341, two denial-of-service advisories, switched off by default, and it keeps the third-party module advisories above. Go toolchain has the detail.
• Snap sync. A response cap in v1.12.23 can disconnect peers that are answering correctly; the August 2026 follow-up measures it. v1.13.0 does not carry that cap.
• GraphQL. v1.13.0 limits query depth. The article is right that GraphQL is off unless --graphql is set.

Review¶

GitHub records no second reviewer’s approval on any 2026 core-geth release, in either repository. A GitHub approval is one way to review a change and it is not the only one, so this section describes the review each release did get, on both sides.

How v1.13.0 is reviewed. Changes are reviewed by automated agents against Ethereum client practice before they land, and the security fixes port changes merged upstream in go-ethereum; the March 2026 audit links each upstream change. The test suites run in CI on every push to main, and the audits measure the published binaries rather than the build configuration. The March pull requests carry review comments from their author and from GitHub’s automated Copilot reviewer. The September commits landed on main directly, after that review and the release candidates.

How the 2026 etclabscore/core-geth releases were reviewed. Each release pull request was opened and merged by the same account, with no review recorded on GitHub:

Contributions are open. ethereumclassic/core-geth has multiple maintainers with admin access and takes pull requests from anyone. #39, from meowsbits, was opened against the old master branch, answered there, and landed in v1.13.0 as --mediumkdf (cab22a882).

This repository uses AI assistance and says so in its AGENTS.md and CLAUDE.md. The description of #694, the v1.12.21 release pull request, also ends “Generated with Claude Code”. What a release does is settled by reading its code and measuring its binaries, which is what the linked audits do.

Test fixtures¶

Commit 693d8e41b changes where the ETC fixture submodule is fetched from and leaves the pinned commit unchanged. Both v1.12.23 and v1.13.0 pin tests/testdata-etc at 06ec708ea7f3707826142a97a94b61d40c920696. A git checkout is verified against that hash, so a copy fetched from anywhere else either matches it byte for byte or fails to check out.

Peer discovery¶

v1.13.0 starts discovery from three bootnodes and three DNS trees. The trees, all.classic.ethereumclassic.net, all.classic.ethclassic.net and all.classic.ethereumclassic.network, are published from the public ethereumclassic/discv4-dns-lists repository by a crawl of the network, and signed by the key in params/bootnodes_classic.go. The crawl published on 2026-09-14 lists 120 Classic nodes.

Discovery lists start a node’s search; they do not choose its peers. After its first contacts a node finds further peers through the discovery protocol itself. --bootnodes and --discovery.dns accept any other list, including the previous trees, which still resolve. Those trees are published from etclabscore/discv4-dns-lists, in the ETC Cooperative’s etclabscore organization. As communicated by the ETC Cooperative board, the Cooperative is scheduled to dissolve by the end of 2026, and these trees to be archived as it does. v1.13.0 dropped them because this project does not hold their signing key (c0b58570d). Bootnodes and peer discovery explains how the lists are built and how to publish your own.

v1.12.22 also moved its discovery tree. Commit 68bc29bbf changed the Classic tree from all.classic.blockd.info to all.classic.etcdisco.net, and it shipped through #696, merged 95 seconds after it was opened, with no review recorded. Its three Classic bootnodes are the same in every release from v1.12.19 to v1.12.23.

Node key rotation¶

The go-ethereum advisory for CVE-2026-26315, GHSA-m6j8-rg6r-7mv8, states: “We recommend rotating the node key after applying the upgrade, which can be done by removing the file <datadir>/geth/nodekey before starting Geth.” The fix stops new leaks; it cannot recall bits of a key that already leaked. A node key that served a v1.12.20 or earlier node should be treated as exposed, whichever later release closed the flaw, and the v1.12.21 release notes do not mention rotation.

Rename that file rather than deleting it. With the node stopped, move geth/nodekey aside; the client writes a fresh one on the next start. Keeping the old file is what lets you prove later which node an old enode ID belonged to, and a deleted key cannot be recovered. Your enode ID changes either way, so update every peer list, monitoring entry and allowlist that names this node. The migration guide gives the commands and the places to update, including why static-nodes.json is not read and has not been for years.

MESS¶

ECBP-1100, which defines MESS, and ECBP-1110, which recommends shipping it off, are Best Practice documents, not consensus rules. MESS changes which of two competing chains a node prefers during a deep reorganization, and never whether a block is valid. The status of both documents is open in ECIPs #580.

What changed, exactly. This client has activated MESS at block 11,380,000 since October 2020, and the v1.12.x line also carries a deactivation at block 19,250,000, the Spiral block, so a node on that line stops applying it there. v1.13.0 removes the deactivation and keeps the activation, so MESS applies again. params/config_classic.go holds both fields and params/config_etc_test.go asserts the deactivation stays unset.

A node with MESS on and a node with MESS off follow the same chain in normal operation. They can only diverge when a competing chain arrives that would replace blocks the node already accepted, which is what a majority-hashrate attack produces rather than ordinary mining. Before MESS existed, one such attack against Ethereum Classic ran for twelve hours on 31 July 2020 and double spent about $5.6 million; the testing report calculates that holding the same reorganization against MESS would have taken 31 times more hashing power.

Whichever you choose, set your own nodes the same. An exchange’s deposit and withdrawal nodes that disagree about MESS can prefer different chains during a deep reorganization, which is the case that matters. --mess=false puts a node where ECBP-1110 recommends, and changing nothing leaves the protection on. Which setting fits which operator has the trade for each kind of node, including the one case where it cuts both ways: a miner with MESS on keeps mining the chain it had if others accept a deep reorganization, and a miner with MESS off follows whichever chain carries the most total difficulty, including one an attacker paid for. MESS has the full record behind the default, and the confirmation calculator shows what it means for deposit confirmations.

Check a release yourself¶

• Checksums and provenance. Verifying a download checks an archive against its published checksum and its build attestation.
• What built a binary. go version -m geth prints the Go version and the commit a binary was built from, without running it.
• Known advisories. govulncheck -mode=binary geth lists the advisories that apply to a binary. Go toolchain explains what it reports for v1.13.0.

Do not trust this page. Verify it.¶

Nothing here asks to be taken on faith, this page included. Every document behind it is public, and so is the article. Fill in the version you run, paste this into ChatGPT, Claude, Gemini or any other assistant that fetches URLs, and make your own decision:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75

I run an Ethereum Classic node on Core-Geth VERSION (replace VERSION with what `geth version` prints).
The node is used for: mining / an exchange / a public RPC endpoint / my own use (keep one).
If I left either line as it stands, do not stop to ask me. Answer for all four bands in question 1.

Two parties have published about this release and both have an interest in what you conclude. Treat
this documentation and that article as claims to be checked against primary records, never as
evidence for themselves. Ignore what either says about motives: it cannot be checked, and my node's
risk does not depend on it.

Published by the Core-Geth maintainers:
https://docs.coregeth.com/release-reports/v1.13.0-record/
https://docs.coregeth.com/audits/2026-03-security-audit/
https://docs.coregeth.com/audits/2026-09-go-toolchain/

Published by Classix:
https://classix.dev/260916-rogue-core-geth-release

Check both against records neither side controls: the GitHub API, or those repositories' own pages
if the API will not load; the CVE, GHSA and Go vulnerability database entries; and the release files
themselves. If a source will not load, say so and carry on with what you can reach.

What the network ran on 17 September 2026, from etcnodes.org, so you need not fetch it: 550 nodes,
524 of them Core-Geth. 1.12.17: 19, 1.12.18: 23, 1.12.19: 35, 1.12.20: 81, 1.12.21: 50, 1.12.22: 165,
1.12.23: 138, 1.12.24: 4, 1.13.0: 9. So 71 percent run something older than 1.12.23 and 30 percent
something older than 1.12.21. Treat 1.12.24 as an unreleased development build, because no such
release exists.

Answer these five. Name a commit, pull request, release file or advisory for every finding. Be
specific: identifiers and dates, not "as documented in the sources".

1. Exposure, for each band: 1.12.17 to 1.12.20, then 1.12.21 and 1.12.22, then 1.12.23, then 1.13.0.
   Separate the client's own CVEs from Go standard library advisories, say which are reachable by an
   unauthenticated peer and what an attacker would need, and say which of them was actually exploited
   against Ethereum Classic bootnodes in March 2026. A version whose client CVEs are closed but whose
   binaries were built on an unsupported Go release is not low risk: give both in the same breath.
   Give one overall verdict per band as well as the detail, and rate no band better than its worst
   unpatched exposure, whether that sits in the client's own code or in the runtime its binaries were
   built with. A label that says low risk above a paragraph describing dozens of unpatched runtime
   advisories is not a verdict.
   Start at https://docs.coregeth.com/release-reports/v1.13.0-record/#what-v1130-fixes-that-v11223-does-not and
   https://docs.coregeth.com/audits/2026-09-go-toolchain/#finding-the-v11220-to-v11223-binaries-carry-go-standard-library-advisories

2. Claims from both sides. Take each factual claim in the article, and each on the maintainers'
   record page, and mark it supported, contradicted or unresolved with the record that settles it.
   Count how many of each side's survived. Where a claim rests on a number of commits or a span of
   days, read what those commits change first: documentation, release engineering and client code are
   not the same thing.

3. When the work was done, and what review it had. Use author dates, not commit dates: a branch
   replayed into another repository carries recent commit dates for older work, and GitHub shows
   both. For each security fix, give the date authored, the date it first appeared in a public pull
   request, and the date it shipped. Then say what review each release on both sides actually
   received: pull requests and reviewers, automated reviewers, whether the change has a reviewed
   upstream original, release candidates, and CI. "No review" is only supported if all of those are
   absent. Start at https://docs.coregeth.com/release-reports/v1.13.0-record/#when-the-work-was-done and https://docs.coregeth.com/release-reports/v1.13.0-record/#review

4. Consensus. Does the release change any rule that decides whether a block is valid? Answer from
   the chain configuration and the commits, not from either side's description. If a change alters
   which of two competing chains a node prefers rather than whether a block is valid, say so plainly
   and say what it does and does not mean for a miner. Start at https://docs.coregeth.com/release-reports/v1.13.0-record/#mess

5. What I should do, and the risk of each option for my kind of node. Say what both sources agree
   on, listing something only if both actually state it. Say what you could not verify and what would
   settle it. If you tell me to change a security default, say in the same sentence what protection I
   give up and under what conditions I would need it, and cite the record for both. Do not propose
   building a client from modified source, or reverting to an unsupported toolchain, as a routine
   option for an operator who has not asked for one. Where a step you recommend deletes or replaces
   something I cannot get back, quote the procedure from the project's own documentation rather than
   writing your own version of it.

Then, separately: two claims are in the air. One, that the previous repository went a long time
without security maintenance while people reported problems. Two, that this release was unnecessary.
Say what the evidence supports for each, including partly, neither, or not checkable.

Do not summarize the documents back to me. Tell me what they mean for my node.

The documents are markdown in the repository under docs/, so a model that prefers raw source can read them there, and git log shows every change any of them has had.