v1.13.0: the record behind the release

Last edited: October 12, 2026

Core-Geth v1.13.0 is stable, and it is the recommended client. It was released on September 14, 2026 after about six months of development tested on Ethereum Classic mainnet and Mordor, and it has now run in production for a month with no critical issue found. It fixes six CVEs and a denial of service that every v1.12.x release still carries, builds every binary on the supported Go 1.26 toolchain, and is developed in the open at ethereumclassic/core-geth, where Ethereum Classic keeps its public goods. The v1.13 line is where Core-Geth is maintained going forward: coregeth.com/downloads has the release files and how to verify them, and the migration guide covers the upgrade.

This page is the record behind that release, set against the claims made about it. An article published on September 16, 2026, the Rogue Core-Geth Release Incident Report, told node operators and mining pools not to run v1.13.0, to move any node already on it back to v1.12.23, and to restore a node key rotated on this project’s instructions. A month of stable operation has answered its prediction of a “potential catastrophe”; its central claim, that nothing in v1.13.0 fixes a vulnerability in v1.12.23, is contradicted by the release files; and its advice would leave a node less secure than the release it warns against.

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 fixes in v1.13.0 were reported privately first and made public nearly six months before it shipped.

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 March 31, 2026, and the site’s earliest post is dated May 11, 2026. Its introduction of September 9, 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.

At a glance

A month after release, the record is plain, and every line of it is checkable against the links below.

• v1.13.0 is stable in production. On the pool nodes that ran it, the article’s own incident record reports “no blocks were lost, no reorg occurred, no funds were affected, and no service went down,” and in the month since, no issue reporting a defect has been opened in this repository. The “potential catastrophe” the article warned of did not happen.
• It fixes vulnerabilities every v1.12.23 archive carries. Those archives carry 67 to 73 Go standard library advisories, each with a CVE identifier; v1.13.0 carries none of them, and clears 44 third-party module advisories besides. The claim that “nothing … fixes a vulnerability in that version” is contradicted by the release files.
• It is maintained where Ethereum Classic keeps its public goods. ethereumclassic/core-geth was created on December 21, 2024 from etclabscore/core-geth at 7ef3ecd7a, the move the Cooperative’s own 2024 retrospective and its Senior Editor had already proposed.
• The work was deliberate, not last-minute. The security fixes opened as pull requests #10 to #36 on 20 and March 21, 2026, from commits authored as early as 26 February; of the 202 commits to v1.13.0, 75 predate September. The September commits are 41 documentation and 31 release engineering, with 17 changing the client, each reviewed against Ethereum client practice, tested on every push, and run through seven release candidates (see Review).
• Discovery, fixtures and the node key are as the release documents them. v1.13.0 starts discovery from DNS trees that list 120 Classic nodes found by crawling the network, published from a public repository, and --bootnodes and --discovery.dns accept any other list; it pins the same fixture commit 06ec708 that v1.12.23 pins, verified by hash; and the node-key rotation it calls for is the one the go-ethereum advisory for CVE-2026-26315 recommends.

Each point is set out in full below, with the record behind it.

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, July 30, 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 December 21, 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.
• 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.

Why the article’s advice reduces security

The article tells operators who upgraded to move back to v1.12.23 and to restore a node key they rotated. Both steps return a node to a worse security position than v1.13.0.

• The published v1.12.23 archives carry the Go standard library advisories v1.13.0 removed. Each carries 67 to 73, all published before it shipped, and its release build cannot be compiled on a supported Go, so the exposure cannot be cleared by rebuilding. Go toolchain lists every one.
• A rotated node key should not be restored. The go-ethereum advisory for CVE-2026-26315 (GHSA-m6j8-rg6r-7mv8) recommends rotating it after the upgrade that fixes the leak; a key that served a v1.12.20 or earlier node should be treated as exposed, and restoring it reinstates that exposure.

The fixes were disclosed first

The security work in v1.13.0 was reported privately to the etclabscore/core-geth maintainers in February and March 2026. It was published as pull requests #10 to #36 on 20 and March 21, 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

v1.13.0 was run on Ethereum Classic mainnet and Mordor throughout its development, from February 2026 to the release in September, and it has now run in production for a month since. No issue reporting a defect in it has been opened in this repository, operators who moved to it report stable nodes, and the scrutiny the release has drawn has surfaced no critical issue, only further cleanup and polish, which v1.13.1 carries. The March 2026 audit and dependency and toolchain modernization record the development 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 September 17, 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 April 16, 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 August 14, 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 February 6, 2026), the blst upgrade for a failing CI job (#691, closed), and dropping the memsize debug endpoint (#701, closed September 17, 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 February 10, 2026 and Go 1.25 on August 19, 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 March 21, 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 May 25, 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

Most of the network runs a release the audits measure as carrying unpatched advisories, and 158 nodes predate the March 2026 emergency patches altogether. The article asked operators to move off v1.13.0; on the day of the snapshot below, nine nodes ran it, and the rest carried the exposure the table records.

Source: etcnodes.org, September 17, 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. That holds for the ETC network, though the v1.12.x line still ships and selects the Ethereum Foundation networks, where the KZG path is active. 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 67 to 73 standard library advisories, all published before v1.12.23, 54 to 58 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 September 14, 2026 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 July 31, 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:

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 September 17, 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 the Core-Geth `v1.12` 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.