Go toolchain: v1.12.x archive to v1.13.0

This document records which Go toolchain built each published v1.12.x release, the Go standard library advisories those binaries carry, what v1.13.0 ships instead, and why an operator on the older line should move. It is a companion to 2026-08-dependency-modernization.md, which covers the toolchain and module changes in the source, and to 2026-09-release-pipeline.md, which measures the same published archives for platform floors and provenance. 2026-03-security-audit.md and 2026-08-security-followup.md cover the CVE remediation in the client’s own code.

Baseline: the four releases v1.12.20 through v1.12.23, published from etclabscore/core-geth, measured by downloading every archive and reading the build information recorded in each binary rather than the configuration that built it. The Linux x86_64 archive of each earlier stable v1.12.x release was measured the same way.

Agentic auditing methods and tooling: the strongest available Claude models at each stage of the work, February through September 2026

Work carried out by: White B0x

Work funded by: Ethereum Classic DAO

Last edited: October 12, 2026

In short

Upgrade to the latest v1.13 release. Each release from v1.12.20 to v1.12.23 was built by two Go toolchains, Go 1.21 and Go 1.22, both out of support before those releases shipped. Across all its archives each of those releases carries 75 Go standard library advisories, 59 of them with the vulnerable code present in the binary; per archive the figure runs from 67 to 73, with 54 to 58 in the binary. Because both Go majors left support in 2024 and 2025, that count only rises as the Go team publishes more advisories, and none of the fixes will ever reach those binaries. The v1.13 line is built on Go 1.26, which is in support and receives those fixes: v1.13.0 shipped on go1.26.8 and carried none when it was released, and v1.13.1 is built on go1.26.9, which carries the October 2026 Go security releases. The upgrade from go1.21.13 to go1.26.9 clears 105 Go standard library and toolchain advisories recorded in the Go vulnerability database. The v1.13.0 release has about six months of testing on Ethereum Classic mainnet and Mordor behind it and a month in production since release, with no critical issue found.

Why the toolchain needed a pass of its own

The Go standard library is compiled into every binary, crypto/tls and net/http included. A Go security release therefore reaches an operator only through a client release built with it, and a binary keeps its toolchain’s advisories for as long as it runs.

The build configuration names a Go version, and the binary records the one that actually built it. go version -m reads that record from a downloaded file without running it. Read from the go-version setting in the release workflow, the v1.12.x releases were built with Go 1.21. Their binaries record two toolchains, and the difference decides which advisories each archive carries.

Finding: each release from v1.12.20 to v1.12.23 was built by two toolchains

Every archive of v1.12.20 to v1.12.23 and of v1.13.0, read from the binaries:

21 of the 32 v1.12.x archives were built with go1.22.1, every Arm archive among them. The other 11 were built with Go 1.21. In these four releases the osx archive is an Apple Silicon build, which release artifacts covers; v1.13.0 publishes the two architectures under separate names.

The split follows two build paths in the release configuration, and the pins were the same at all four release commits. The release workflow installed Go with go-version: '1.21' and built the Linux x86_64, macOS and, from v1.12.21, Windows archives with it. The Arm archives were built with build/ci.go install -dlgo, which downloads the Go version pinned in build/checksums.txt: 1.22.1. The v1.12.20 Windows archive came from AppVeyor, which also used -dlgo.

Every v1.13.0 node archive, and geth in the two core-geth-docker image tarballs attached to the release, was built with go1.26.8.

Both older majors are out of support. Go’s release policy: “Each major Go release is supported until there are two newer major releases.”

The 2026 releases shipped after both majors had left support. The toolchains on each release date:

Their Go 1.21 archives carry go1.21.13, the last Go 1.21 release, so nothing newer exists on that branch: every fix published after August 2024 shipped only in newer Go majors. Their Arm archives carry go1.22.1, which was missing seven later security releases on its own branch, and Go 1.22 had no release after February 2025. v1.12.20, published while both majors were still supported, already shipped behind the newest patch of each.

The earlier releases are on unsupported majors as well. The Linux x86_64 archive of every stable release from v1.12.0 to v1.12.19 was measured too. Across those and the 32 above, the 50 v1.12.x archives measured were built with eight Go majors, from Go 1.13 to Go 1.22, and none of them is supported today. Two of those releases shipped on a major that had already left support: v1.12.2 (go1.13.4) and v1.12.10 (go1.18.10).

Finding: the v1.12.20 to v1.12.23 binaries carry Go standard library advisories

The Go vulnerability database lists 75 standard library advisories that apply to at least one archive of v1.12.20 to v1.12.23, read with govulncheck against the database snapshot recorded under Verification. That figure was 62 when this audit first measured it against the September 15, 2026 database; the October 2026 Go security batch, published October 8, 2026, added 13 more. The binaries have not changed, so the rise is new advisories reaching an unchanged, out-of-support toolchain, and it continues. Two levels matter:

• Module level: the toolchain version is in the advisory’s affected range, for the archive’s operating system and architecture.
• Symbol level: a function the advisory lists as vulnerable is present in the binary.

Presence is not proof of reachability. Whether the client can reach the vulnerable code was not assessed for any advisory on this page.

Counts are distinct advisories across all archives of a release, read against the current database recorded under Verification. “Already published that day” counts those whose database entry was published on or before the release date. 62 of the 75 had been published when v1.12.23 shipped; the other 13 are the October 2026 Go batch, published October 8, 2026. The v1.12.20 count is lower in that column only because most were published after it, and its binaries carry all 75 regardless.

The two v1.13 rows read differently, and the difference is the point. v1.13.0 was built with go1.26.8 and carried none of these when it was released, measured against the database as it stood the day after. The same October batch that added 13 advisories to the v1.12.x binaries also reaches go1.26.8 at module level, because its fix is in go1.26.9, so a scan today reports 12 against the published v1.13.0, 9 of them with the code in the binary. The v1.12.x binaries will never receive those fixes, because Go 1.21 and Go 1.22 are out of support. v1.13.1 is built with go1.26.9, which carries them, and reports none. A supported toolchain takes each Go security release on its next build, and Core-Geth’s weekly govulncheck workflow is what surfaces the gap in between. This is the supported-Go path working as intended, not a defect in v1.13.

Per archive, in v1.12.23:

The linux figures were re-measured against the current database. The osx, win64 and arm figures add the October 2026 advisories to the per-archive counts this audit measured against the September 15, 2026 database: 12 that apply to every archive by toolchain version, 11 of them with the vulnerable code in the binary, and one more at module level on win64 only (GO-2026-6604, os.Root.Mkdir following junctions out of the root on Windows, whose symbol cannot be present in a go1.21.13 binary because os.Root postdates Go 1.24). The toolchains and the symbol surface of these packages are the same source across architectures, so the additions do not depend on re-reading each binary; see Verification.

From v1.12.21 on, the go1.22.1 archives carry five advisories the Go 1.21 archives of the same release do not. Two were never in a Go 1.21 archive, and go1.21.13 includes the fixes for the other three, which go1.22.1 predates:

Three depend on the operating system: GO-2025-3750 and GO-2026-6604 apply only to Windows, and GO-2026-4864 only to Linux.

What these advisories are, and which packages a node exposes

The Go vulnerability database assigns no severity to these entries, and this page adds none of its own. A count on its own invites the reply that the advisories are a scanner artifact with no bearing on a node, so this section says what they are and where they sit. Every one is a fix the Go team shipped in a numbered security release, and the CVEs carry CVSS scores in the National Vulnerability Database.

The largest groups are in the standard-library packages this client serves to the network. Of the 68 on the Linux archive: 16 are in net/http (counting net/http/internal and the x/net/idna entry it pulls in), 8 in crypto/x509, 7 in crypto/tls, 4 in net/url, 3 in net/textproto, 2 in net and 2 in encoding/asn1. This client runs net/http servers for its JSON-RPC, WebSocket, GraphQL, metrics and pprof endpoints (node/endpoints.go, node/rpcstack.go), uses crypto/tls and crypto/x509 with encoding/asn1 and encoding/pem for TLS and certificate handling, and resolves its DNS-based peer-discovery lists through net. Many are denial-of-service class and reachable without authentication: the HTTP/2 CONTINUATION flood (GO-2024-2687), request smuggling through invalid chunked data (GO-2025-3563), cookie-parsing memory exhaustion (GO-2025-4012), the HTTP/2 SETTINGS_MAX_FRAME_SIZE infinite loop (GO-2026-4918), the unauthenticated TLS 1.3 KeyUpdate connection-retention DoS (GO-2026-4870), a crash on a long DNS CNAME response (GO-2026-4981), and the October 2026 HTTP/2 batch (flow-control, Trailer and HPACK-race defects in the server).

The rest are in the standard library but concern inputs a node does not take from untrusted peers in normal operation, and are listed for completeness rather than as node exposures: html/template (HTML template injection and cross-site scripting, where this client serves JSON rather than rendering templates), go/parser, go/build/constraint and encoding/gob (stack exhaustion parsing sources a node does not accept over the network), and archive/tar, archive/zip, net/mail and mime.

Reachability of a specific crafted input was not tested for any advisory here, which Verification records among what was not measured. The grouping above is by the package a node links and exposes, not a proof of exploitability. Two things do not depend on it. The fixes exist, and the v1.12.x toolchains will never receive them, because Go 1.21 and Go 1.22 left support in 2024 and 2025. The total was 62 a month ago and is 75 now, and it only grows.

Finding: the v1.12.x source does not build on a supported Go

Rebuilding a v1.12.x release with a supported Go would take the standard library fixes if the source built. It does not. At the v1.12.23 release commit, built with go1.26.6 using the build tags and C flags recorded in the published v1.12.23 binary, the build stops at two independent blockers, in this order.

blst v0.3.11 does not compile from Go 1.24. The release build sets the ckzg tag, as make geth and make all do, and the KZG binding it enables imports blst. The build fails in blst’s Go bindings with cannot define new methods on non-local type SecretKey, and the same error for Fp12, P1Affine and P2Affine. From the Go 1.24 release notes:

The compiler already disallowed defining new methods with receiver types that were cgo-generated, but it was possible to circumvent that restriction via an alias type. Go 1.24 now always reports an error if a receiver denotes a cgo-generated type, whether directly or indirectly (through an alias type).

Upstream go-ethereum moved to blst v0.3.14, whose release carries a fix for Go 1.24, in #31165, first released in go-ethereum v1.15.1.

fjl/memsize does not link from Go 1.23. Without the ckzg tag the build reaches the linker and stops at link: github.com/fjl/memsize: invalid reference to runtime.stopTheWorld. memsize backs the /memsize/ page of the pprof debug server and refers to runtime internals through //go:linkname. From the Go 1.23 release notes:

The linker now disallows using a //go:linkname directive to refer to internal symbols in the standard library (including the runtime) that are not marked with //go:linkname on their definitions.

Upstream go-ethereum removed memsize ahead of Go 1.23, in #30253: “Removing because memsize will very likely be broken by Go 1.23”. That change was first released in go-ethereum v1.14.8.

Removing memsize alone does not produce a build. With the ckzg tag the release configuration sets, the blst compile error comes first on any Go from 1.24. Leaving the tag out as well does produce one, and operators have run v1.12.23 built that way on a current Go.

A toolchain swap alone also keeps Go 1.21’s defaults. The go 1.21 directive in go.mod keeps Go 1.21’s compatibility settings when a newer Go builds the module. All 21 go1.22.1 archives record them:

DefaultGODEBUG=httplaxcontentlength=1,httpmuxgo121=1,tls10server=1,tlsrsakex=1,tlsunsafeekm=1

On a Go from 1.24 on, the same directive switches off two denial-of-service fixes. Go added httpcookiemaxnum, a limit on the cookies net/http parses, and urlmaxqueryparams, a limit on the query parameters net/url parses, as the fixes for GO-2025-4012 and GO-2026-4341. Its compatibility table gives a module declaring a Go older than 1.24 the value 0 for both, which, in the words of Go’s GODEBUG history, accepts “an indefinite number of cookies” and “disables the limit”. go1.26.6 and go1.27.1 carry the same entries. So a v1.12.23 rebuilt on a current Go reports a Go version whose standard library carries those fixes, with both limits off. Setting GODEBUG=httpcookiemaxnum=3000,urlmaxqueryparams=10000 at run time turns them back on.

The previous repository records both blockers. In etclabscore/core-geth:

• #680, an issue opened 2025-04-30, reports that v1.12.20 does not compile with go1.24.0, and its build log shows the blst v0.3.11 errors above. It was closed on June 29, 2025 with the reply “Go 1.24 is not supported, please try Go 1.21”.
• #683, a pull request titled “Support go 1.24 compiler” and opened June 30, 2025, changes go.mod, internal/debug/flags.go, the workflows and the Dockerfiles. Its description says it fixes #680 and #665, an earlier pull request that removes memsize. It was closed without being merged on February 6, 2026.
• #690, an issue opened 2025-11-10, reports the AppVeyor build failing inside blst v0.3.11’s header with 'bool' cannot be defined via 'typedef', and #691, a pull request opened the same day, upgrades blst in go.mod to address it. That failure comes from the C compiler rather than from Go: it is the C23 finding in release artifacts.
• #701, a pull request opened 2026-09-15, removes memsize and its debug endpoint, citing the link error above. On its own that change does not clear the blst error.

v1.13.0 carries blst v0.3.17, no memsize, and go 1.26.0 in go.mod. Its binaries record no DefaultGODEBUG override.

Finding: third-party module advisories were cleared alongside

The same scans cover the modules compiled into each binary. In v1.12.23, govulncheck matches 47 advisories against third-party modules at module level, 9 of them at symbol level. 44 are absent from v1.13.0, 3 remain, and none is new. The main module, github.com/ethereum/go-ethereum, is not counted here; the scanner section covers it.

The three that remain are golang.org/x/crypto advisories, described in the scanner section. Four of the 44 also cover the standard library and appear in the list of 75 above. Dependency and toolchain modernization records the module changes themselves.

What a vulnerability scanner reports against v1.13.0

Standard library. No Go standard library advisory applied to any of the nine v1.13.0 archives, or to geth in either core-geth-docker image tarball, even at module level, when they were measured against the database as it stood on September 15, 2026: go1.26.8 was the newest Go 1.26 release that week and nothing in the database reached it. The October 2026 batch changed that for the published go1.26.8 binary, as the finding above records: against the current database it matches 12 advisories at module level, 9 with the code present, every one fixed in go1.26.9. v1.13.1 is built with go1.26.9 and matches none. The difference between a supported toolchain and an out-of-support one is exactly this: go1.26.8 receives the fix on the next build, and go1.21.13 and go1.22.1 never will. See After v1.13.0 for the weekly scan that tracks it.

Three golang.org/x/crypto advisories, at module level only. v1.13.0 ships golang.org/x/crypto v0.55.0, which is in the affected range of three advisories:

The affected packages are not compiled into any v1.13.0 binary. No golang.org/x/crypto/ssh or golang.org/x/crypto/openpgp function name occurs in any of them, while other golang.org/x/crypto functions do.

The two macOS archives show those three at symbol level. govulncheck reads no symbols from the v1.13.0 osx and osx-arm64 binaries. When it reads none, it handles the binary as stripped and reports every listed vulnerable symbol of every module-level match, so a scan of either archive lists symbol-level golang.org/x/crypto/ssh and golang.org/x/crypto/openpgp findings for code the binary does not contain. Their module-level results are unaffected. The same scanner read symbols from the v1.12.x macOS archives. The v1.13.0 macOS binaries were linked with -s, which removes the symbols it looks for; After v1.13.0 gives the detail and the change.

Six go-ethereum advisories, all fixed in v1.13.0. Every v1.13.0 archive matches six advisories filed against go-ethereum, at symbol level, and the match is structural. The Go module path is deliberately github.com/ethereum/go-ethereum, which is what makes this client a drop-in downstream. The scanner compares this client’s version with go-ethereum’s version ranges, and v1.13.0 sorts below the go-ethereum releases that fixed these, so each one matches whether or not its fix is present. Matching on symbol names does not settle it either, because a backported fix adds its guard inside the same function. Release artifacts describes how to read such a scan. Each match was confirmed by reading the guard at the v1.13.0 tag:

What this means if you are upgrading

• Rebuilding a v1.12.x release on a newer Go takes the standard library fixes, but not all of what upgrading does. The build needs memsize removed and the KZG build tag left out. It still declares go 1.21, so two denial-of-service limits stay off unless GODEBUG sets them, and it keeps the third-party module advisories and everything else v1.12.23 carries. v1.13.0 declares go 1.26.0 and is built with go1.26.8.
• Arm builds of v1.12.x carry the most. Every Arm archive from v1.12.20 to v1.12.23 carries 73 standard library advisories at module level, against the current database.
• Go 1.26 is supported until go1.28.0 is released, under the policy above, and go1.26.9 is the current Go 1.26 security release. A Go security release reaches your node only through a Core-Geth release built with it, so follow the ethereumclassic/core-geth release line and run the latest.

Verification

Each check below was calibrated so that it could report a negative:

• The published files. 59 node archives were downloaded: every archive of v1.12.20 to v1.12.23 and v1.13.0, and the Linux x86_64 archive of each earlier stable v1.12.x release. Each matched its published .sha256, and the 33 from 2026 releases also matched GitHub’s server-side digest, which the older release assets do not carry. Both v1.13.0 core-geth-docker image tarballs matched as well.

• The source they came from. Each binary’s recorded vcs.revision equals the commit its release tag points to.

• The toolchain. Read from each binary’s build information with go version -m. No downloaded binary was executed.

• The advisories. The baseline figures of 62 at module level and 48 at symbol level were read with govulncheck v1.7.0 in binary mode, at symbol level and at module level, on all 41 binaries of v1.12.20 to v1.13.0, against one snapshot of the Go vulnerability database for every scan: vuln.go.dev as modified 2026-09-15T18:39:25Z, 4,445 entries, SHA-256 fe51e51645e6b1e946731cef048339972256c6417de91d4cf3985fc87b4aa89b.

• The October 2026 refresh. The current figures of 75 at module level and 59 at symbol level were read with govulncheck v1.8.0 against vuln.go.dev as modified 2026-10-08T22:31:09Z, 4,613 entries, the October Go security batch included. The Linux x86_64 binary of v1.12.23 was re-scanned directly and reports 68 at module level and 54 at symbol level, up from 56 and 43. The 13 added advisories apply to the other archives by toolchain version and operating system: 12 to every archive at module level, 11 of those with the code in the binary, and GO-2026-6604 at module level on win64 only. Those additions were applied to the per-archive counts the baseline measured, rather than by re-downloading each archive; the toolchains are unchanged and the symbol surface of these packages is the same source across architectures. A go1.26.9 binary, the toolchain of v1.13.1, reports no standard library advisory against the same database.

• Calibration in both directions. Against the current database every v1.12.20 to v1.12.23 archive reports 67 to 73 standard library advisories at module level, and the Linux x86_64 binary 68. A Go binary built with go1.26.6, the last Go 1.26 release before the October batch, reports 12, every one fixed in go1.26.9; one built with go1.26.9 reports none. Against the baseline September 15, 2026 database that same go1.26.6 binary reported none, and a binary built with go1.26.1 reported 28, fixed in go1.26.2 to go1.26.6.

• An independent re-derivation. Each advisory’s version ranges were evaluated directly against each binary’s Go version and module versions, excluding withdrawn entries and applying the same operating system and architecture filter as govulncheck. The result matched govulncheck’s for all 41 binaries, including the first fixed Go version of every standard library match.

• Whether the scanner read symbols. govulncheck read between 49,101 and 53,753 symbols from 39 of the 41 binaries, and none from the two v1.13.0 macOS binaries described above. The absence of golang.org/x/crypto/ssh and golang.org/x/crypto/openpgp function names was checked in all 41, against other golang.org/x/crypto names present in every one.

• Release-date counts. “Already published that day” uses each advisory’s published date. Counting instead by the release date of the first Go version that fixes it gives the same figure for every archive of every release.

• The failed build. At the v1.12.23 release commit, with go1.26.6 and modules verified against its go.sum, this command exits 1 with the blst compile error, and the same command without the ckzg tag exits 1 at the link step with the memsize error:

  GOTOOLCHAIN=local CGO_CFLAGS="-O2 -g -D__BLST_PORTABLE__" go build -p 4 -tags urfave_cli_no_docs,ckzg ./cmd/geth

Not measured:

• The core-geth-alltools archives and image tarballs, so the go1.26.8 result for v1.13.0 is established for geth only.
• Container images published to a registry, for any release, including v1.12.x images built from golang:1.22-alpine.
• Archives of v1.12.0 to v1.12.19 other than Linux x86_64, and govulncheck on any of them.
• Prereleases and drafts.
• Builds on Go 1.23, 1.24, 1.25 or 1.27. The Go release each blocker arrived in comes from Go’s release notes and source, not from building on it.
• Reachability of any advisory from the client’s code paths.
• go-ethereum advisories against the v1.12.x binaries. Those record the main module’s version as (devel), which govulncheck never matches, so their absence is not evidence either way.
• Why the release workflow’s go-version: '1.21' produced go1.21.10 on June 10, 2024, when go1.21.11 had been released on June 4, 2024, and how the v1.12.2 Linux archive came to be built with go1.13.4.
• Issues and pull requests in etclabscore/core-geth beyond those listed above, which were found by search and screened by title.

After v1.13.0

Each of these is resolved on main for the next release. None changes what v1.13.0 ships or how it behaves.

• The toolchain and dependencies for v1.13.1. v1.13.1 moves the build to go1.26.9, which carries the October 2026 Go security batch above, and golang.org/x/net to v0.60.0, which carries the same HTTP/2 fixes on the x/net side. The x/net bump resolves golang.org/x/crypto to v0.57.0, golang.org/x/text to v0.42.0, golang.org/x/sys to v0.48.0, golang.org/x/mod to v0.41.0 and golang.org/x/sync to v0.23.0, each an upgrade. x/crypto v0.56.0 and later fix GO-2026-6354 and GO-2026-6355 in golang.org/x/crypto/ssh, and x/mod v0.40.0 and later fix GO-2026-6179 and GO-2026-6180 in golang.org/x/mod/sumdb; v1.13.0 compiles none of those ssh, sumdb or openpgp packages into any binary, so they were never a concern for it. GO-2026-5932, in golang.org/x/crypto/openpgp, has no fixed version and is not compiled into any binary either. A govulncheck scan of a v1.13.1 build reports no Go standard library advisory.
• A weekly scan. .github/workflows/govulncheck.yml scans main every week, in source mode and against a geth binary built with the release Go version, and keeps one issue current with anything that needs a maintainer. The six go-ethereum advisories above are expected; one of them disappearing is reported too.
• The macOS symbol table. The release build linked the macOS binaries with -s, which removes Go’s symbols from the Mach-O symbol table. govulncheck looks up the go:func.* symbol there and, without it, reports at module level, although the __gopclntab function table it reads next is present. build/ci.go now links them with -w, which strips only the debugging information. A go1.26 macOS test binary linked with -w keeps go:func.* and every Go symbol; one linked with -s keeps none.

Disposition of the build finding, September 17, 2026

The finding that the v1.12.x source does not build on a supported Go now has a proposed remedy in the repository that publishes that line. Pull request #702 at etclabscore/core-geth, opened September 17, 2026 and unmerged when this was written, makes the three changes this audit measured as necessary: it removes github.com/fjl/memsize, whose //go:linkname use Go 1.23 restricted; it moves github.com/supranational/blst from v0.3.11, which Go 1.24 rejects for a cgo alias receiver, to v0.3.16; and it raises the go.mod directive from go 1.21 to go 1.24.0. It also moves 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.

Two measurements to repeat rather than assume, if that release ships. Go 1.24 left support on 10 February 2026 and Go 1.25 on August 19, 2026, each when two newer major releases existed, so a binary built from either would still carry standard library advisories, fewer than Go 1.21 carries. And the advisory count for any such release has to be measured from its published archives, the way the counts in this document were, rather than inferred from the go.mod directive: this audit found two toolchains per release where the configuration implied one.

This paragraph records a disposition, which is what an audit finding is supposed to acquire. It is not a claim about anyone’s reasons.

Supporting this work

The client is maintained by Ethereum Classic’s core developers and open community contributions, in the ethereumclassic GitHub organization. The Ethereum Classic DAO is the legal entity standing behind that work, and the floor under it when nobody else is paying. Mining pools, centralized exchanges, issuers of Ethereum Classic financial products, Etchash mining hardware manufacturers and large holders all depend on this client. If your operation relies on Ethereum Classic, please consider sponsoring its maintenance. Support this work says who maintains and funds it and how to sponsor it.