Release binary reports 20 HIGH CVEs (Go toolchain, x/crypto, docker/docker)

[davidham]

Summary

A Trivy scan of the gh-ost binary shipped in the v1.1.10 release reports 20 HIGH severity CVEs (0 critical). All of them come from the Go toolchain the binary was built with, and from two modules recorded in its build info.

This is a practical blocker for regulated deployments. We embed the released binary in a downstream image for a FedRAMP-authorized platform, which cannot ship an image containing any Critical or High CVE.

Findings

Scanning the v1.1.10 linux/amd64 binary (trivy rootfs --scanners vuln --severity HIGH,CRITICAL):

Source	Version in binary	Count	CVEs
Go stdlib (build toolchain)	go1.25.9	8	CVE-2026-27145, -33811, -33814, -39820, -39822, -39836, -42499, -42504
golang.org/x/crypto	v0.45.0	9	CVE-2026-39828, -39829, -39830, -39831, -39832, -39835, -42508, -46595, -46597
github.com/docker/docker	v28.0.1+incompatible	3	CVE-2026-34040, CVE-2026-41567, CVE-2026-42306

Why docker/docker is in a schema-migration binary

go/logic/test_utils.go has no _test.go suffix, so it is part of the ordinary build of package logic. It imports testcontainers-go, and package logic is imported by go/cmd/gh-ost, so testcontainers and its transitive dependencies -- including github.com/docker/docker -- get compiled into the released binary and recorded in its build info.

go version -m on the v1.1.10-equivalent binary records 60 modules, most of which are container-testing infrastructure that never runs in production.

Notably, this cannot be fixed by bumping the dependency. All three docker CVEs are first patched in 29.3.1, but at v29 the module was renamed to github.com/moby/moby/v2, and the v29 tags are named docker-v29.x.y, which Go cannot resolve as module versions. The github.com/docker/docker path is frozen at v28.5.2+incompatible, so there is no reachable fixed version on that path.

Suggested fix

1. Rename go/logic/test_utils.go to test_utils_test.go. Every identifier it declares is referenced only from applier_test.go, streamer_test.go and migrator_test.go, so this is a no-op for behavior but drops testcontainers, docker/docker and x/crypto out of the shipped binary.
2. Bump golang.org/x/crypto to v0.52.0 so the module manifest is clean for source-level scanners.
3. Bump the pinned Go toolchain to 1.26.5. Most stdlib CVEs are fixed by 1.25.10/1.26.3, but CVE-2026-39822 is not fixed until 1.25.12 / 1.26.5.

Together these take the linux/amd64 binary from 20 HIGH/CRITICAL to 0, and reduce recorded modules from 60 to 22.

I have this working and verified locally (build, full unit suite, golangci-lint, gofmt all clean) and will open a PR shortly. Happy to adjust the approach if you would prefer to solve the test_utils.go scoping differently.

[ericyan]

Thanks for the report.

I decided to take a slightly different approach to address those vulnerabilities:

• x/crypto has been upgraded to v.0.54.0 instead of v0.52.0
• I upgraded testcontainers as well, this moves the dependency from github.com/docker/docker to github.com/moby/moby
• For Go, I decided to use v1.25.12 for now. A major version upgrade to 1.27 is planned next month, and this patch version should also fixes all the CVEs you listed.

I think it still worth to do the testutil rename: github.com/testcontainers/testcontainers-go does not belong to the built binary. Would you rebase and cherry-pick your PR?