security: Go toolchain 1.26.9, and the Docker builder on Go 1.27.2 (12 stdlib advisories)

[distronode-com]

A security toolchain bump. No code or dependency change.

What was wrong. govulncheck ./... reports 12 published Go standard-library vulnerabilities as reachable from Calnode on the toolchains main uses today: toolchain go1.26.6 in go.mod (what CI and the audit workflow run on, via go-version-file) and golang:1.27.1-alpine (what the Docker image is built with). The Go vulnerability database lists every one as fixed in both Go 1.26.9 and Go 1.27.2:

• GO-2026-6599, GO-2026-6600 (html/template)
• GO-2026-6603, GO-2026-6610, GO-2026-6611, GO-2026-6612, GO-2026-6617 (HTTP/2: net/http on 1.26, net/http/internal/http2 on 1.27)
• GO-2026-6605, GO-2026-6609, GO-2026-6613 (net/http)
• GO-2026-6607 (crypto/tls)
• GO-2026-6608 (net/textproto)

What this changes.

• go.mod: toolchain go1.26.9, staying on the 1.26 line main already uses. The go directive stays 1.26.0.
• Dockerfile: FROM golang:1.27.2-alpine, the patch release of the line Dependabot moved the builder to (chore(deps): bump golang from 1.26.6-alpine to 1.27.1-alpine #74).
• CHANGELOG.md: a Security entry under Unreleased.

Checked, locally on both go1.26.9 and go1.27.2: pnpm build in frontend/, then go build ./... and go test ./... pass, and govulncheck ./... reports "No vulnerabilities found". gosec ./... (v2.29.0, what @latest resolves to) is clean on go1.26.9: 134 files, 0 issues.

We run a fork of Calnode and found this through its weekly audit; sending the same bump upstream.

🤖 Generated with Claude Code

[pullfrog]

✅ No new issues found.

Reviewed changes — a Go toolchain security bump across the two places the Go version is pinned, plus its changelog entry (3 files, 1 commit, 2107ed9).

• go.mod: toolchain go1.26.6 → go1.26.9. The go 1.26.0 language directive is deliberately untouched, so this is a toolchain-only move. CI (ci.yml:46) and the audit workflow (audit.yml:86) both resolve their Go via go-version-file: go.mod, so they pick the new patch up automatically.
• Dockerfile:19: builder golang:1.27.1-alpine → 1.27.2-alpine. Verified the tag exists and is current for the 1.27 line (multi-arch, incl. arm64 and the TARGETARCH set docker-publish.yml builds). The released binary's stdlib comes from this stage, not from the go.mod toolchain line.
• CHANGELOG.md: ### Security entry under Unreleased, listing the 12 advisories and both version moves, in the repo's existing Keep a Changelog style.

Cross-checks I ran: both versions are the latest patch of their line (1.26.9 and 1.27.2, both released 2026-10-08); no other file pins a Go version — CONTRIBUTING.md says Go 1.26+, still true, and AUDIT.md/audit/claims.yaml pin no version; and docker-publish.yml builds the image on every PR, so the new base image gets exercised before merge.

ℹ️ The two Go lines are now decoupled

Not a problem with this PR — but worth knowing, because the go.mod bump alone would not have closed anything for shipped builds. Since #74 the Dockerfile has tracked 1.27.x while go.mod tracks 1.26.x, and GOTOOLCHAIN=auto means the builder simply uses its own newer 1.27.2 toolchain rather than the pinned 1.26.9. So the audit's govulncheck run verifies the 1.26 line, while every released binary is built with the 1.27 line. Both are latest today, so there is no exposure — just no mechanism that keeps them in step when the next patch lands.

Technical details

# Two independently-versioned Go toolchains

## Affected sites
- `Dockerfile:19` — builder image, now `golang:1.27.2-alpine`, sets the stdlib actually compiled into released binaries.
- `go.mod:5` — `toolchain go1.26.9`, sets the toolchain CI (`ci.yml:46`) and the audit workflow (`audit.yml:86`) run, and therefore what `govulncheck ./...` in `audit.yml:106` reports against.
- `audit/claims.yaml` / `AUDIT.md` — the `clean-security-scan` claim is evidenced only by the CI run, i.e. only for the 1.26 line.

## Required outcome
Nothing, for this PR. Flagged only so the next toolchain bump knows it must touch both files, and so a future `clean-security-scan` claim is not read as covering the shipped binary.

## Open questions for the human
Whether to pin the Dockerfile builder to the same line as `go.mod` (or to its newest patch) so a single bump closes both, versus leaving the builder intentionally ahead. Worth settling before the next CVE, not here.

  ^{｜ View workflow run ｜ Using space-bunny-free (free) ｜ 𝕏}