Bump the Go toolchain to 1.26.7 for four stdlib advisories

[jeremy]

govulncheck against this tree on go1.26.5 reports four Go standard library vulnerabilities, all fixed in go1.26.6 (this repo pinned go 1.26.4, which is older still):

ID	Package
GO-2026-6218	net/url
GO-2026-6090	crypto/tls
GO-2026-5972	encoding/asn1
GO-2026-5026	net/http

Nothing in the source changed — the pin simply aged past the advisories.

I found this while bumping basecamp/cli, which runs a govulncheck job and went red. This repo has no such job, so it was silently affected rather than visibly broken. kamal-proxy and basecamp-installer are in the same position and have matching PRs.

Deliberately not fixed here

Two findings survive the bump and are left alone on purpose:

• GO-2026-4887 — Moby AuthZ plugin bypass on oversized request bodies (CVE-2026-34040)
• GO-2026-4883 — Moby off-by-one in plugin privilege validation (CVE-2026-33997)

Both are in github.com/docker/docker@v28.5.2+incompatible and report Fixed in: N/A for that module path. The fix exists only in github.com/moby/moby/v2 >= 2.0.0-beta.8 — a module-path migration onto a beta release. Both are also daemon-side plugin-authorization bugs, and we consume docker as a client; the traces govulncheck reports here run through shared client error-handling (internal/docker/errors.go), not the AuthZ paths.

That's a real decision with real cost, and it isn't a toolchain bump. Flagging it rather than bundling it.

Verification

Same tree, toolchain swapped:

go1.26.5 → 4 stdlib vulnerabilities (+ the 2 docker findings above)
go1.26.7 → 0 stdlib vulnerabilities (the 2 docker findings remain)

go build, go vet and gofmt -l pass on 1.26.7; the 10 unit packages pass. Two integration/ tests (TestRestore, TestRestoreWithPostRestoreHook) fail on my machine, but they fail identically on unmodified main with the old pin, so they're environmental here and not from this change — CI is green on main.

---

Why this needed a human, and how to stop that

Nothing is going to bump this pin for us:

• Dependabot does not update the Go go/toolchain directive. It's an open feature request — dependabot-core#13520, filed 2025-11-11, still open. Our gomod config groups and cools down module updates and never touches the toolchain.
• GitHub raises no security alert for a vulnerable toolchain version in go.mod either, per that same thread. So neither the version-update nor the security-update path covers it.
• check-latest: true on setup-go would not have saved us here: it re-resolves the version spec, so against an exact 1.26.7 it's a no-op. It only floats when the spec is a range (1.26, stable, oldstable).

That leaves a real choice, and it's worth making deliberately rather than by default:

	reproducible	self-healing
patch-pin, as here (go 1.26.7)	✅	❌ needs a manual bump
go-version: stable + check-latest: true	❌ toolchain floats	✅
bare minor (go 1.26, no check-latest)	❌	❌

The third row is the trap, and it's what basecamp/cli was on: the spec floats but setup-go satisfies it from whatever patch the runner image happens to cache, so it silently pinned to a stale toolchain that later went vulnerable. Worth avoiding in either direction.

The bigger gap is detection, not the pin. This repo has no govulncheck job, which is why the exposure was silent — basecamp/cli runs one and is the only repo that noticed. I'd suggest adding govulncheck here on a schedule rather than as a PR gate: an advisory published against a toolchain is time-based, not diff-based, so gating PRs on it means unrelated work goes red the moment a CVE drops (which is exactly what just happened to cli #64). A nightly run that reports is the signal; blocking every PR is the tax.

Happy to send that as a follow-up if you want it — deliberately not folded into this bump.

[Copilot]

Pull request overview

Updates the root Go toolchain pin to address standard-library vulnerabilities.

Changes:

• Changes go.mod from Go 1.26.4 to 1.26.7.
• Other repository toolchain pins remain unchanged.

Tip

If you aren't ready for review, convert to a draft PR.
Click "Convert to draft" or run gh pr ready --undo.
Click "Ready for review" or run gh pr ready to reengage.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f5c8e5e40e

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".