fix: bump extras/dagger Go toolchain for GO-2026-6617-stdlib

[chainloop-platform]

Summary

Bump the Dagger helper module's Go toolchain directive from 1.26.1 to 1.26.9 so its stdlib metadata no longer points at a vulnerable release line. The production root module was already on Go 1.27.2, so this is the smallest change needed to remove the stale vulnerable toolchain declaration.

Vulnerability Fixed

GO-2026-6617-stdlib (HIGH): HTTP/2 servers can crash if concurrent HPACK encoder updates race while handling SETTINGS_HEADER_TABLE_SIZE changes from a client.

Changes Made

• Updated extras/dagger/go.mod from go 1.26.1 to go 1.26.9, the first fixed release identified for the Go 1.26 line.
• Left the root module unchanged because go.mod already pins Go 1.27.2, which the assessment identified as fixed.
• Kept the remediation scoped to the Dagger helper module because its stale Go directive was the only remaining vulnerable toolchain declaration in the repository.

Verification

Ran syft dir:. -o cyclonedx-json=- | grype sbom:- --only-fixed -o json from the repository root against the patched source tree. Outcome: resolved for GO-2026-6617-stdlib, which is no longer reported in the SBOM scan after the extras/dagger/go.mod toolchain bump.

Risk Assessment

View the risk assessment in Chainloop

[chainloop-platform]

AI Session Checks — ⏭️ bypassed by label

AI Coding Session Check Bypassed

This PR carries the skip-ai-session label, so the AI coding session check was bypassed.

Learn more about Chainloop Trace.

---

Powered by Chainloop and Chainloop Trace

[migmartri]

1.26.8 is the max the module supports, double check wether that's enough to fix the vuln

[migmartri]

1.26.8 is not enough. The Go vulnerability database (GO-2026-6617, CVE-2026-97032) lists the stdlib fix in go1.26.9 (and go1.27.2 on the 1.27 line). The affected range is < 1.26.9. A go 1.26.8 directive would therefore not fix it. Scanners that read the go directive would still flag it, so the change would not even hide the finding.

The directive also does not choose the stdlib that the module runs with. The go line is only a minimum. The module is compiled inside the Dagger engine with the Go SDK image bundled into that engine release. Dagger v0.21.10 (the newest release, pinned in lint.yml and dagger.json) bundles golang:1.26-alpine as it was at build time, which is Go 1.26.8. The SDK image sets GOTOOLCHAIN=auto, but Dagger codegen (also built with 1.26.8) rejects the module before a newer toolchain could be fetched: bootstrap package: existing go.mod has unsupported version 1.26.9 (highest supported version is 1.26.8). That is the lint-dagger-module failure. So the built module uses 1.26.8 stdlib now, and it will keep using it with either directive until Dagger ships a newer engine.

Real exposure is low. The bug is an HTTP/2 server crash (an HPACK encoder race when handling SETTINGS). This module is a short-lived Dagger function that acts as a client of the engine. It does not serve HTTP/2 to untrusted clients. The main module is already on go 1.27.2, which is fixed.

Options:

1. Wait for a Dagger release built with Go >= 1.26.9 (none is out yet; v0.21.10 is the latest). Then bump DAGGER_VERSION, engineVersion and the go directive together. Keep this PR open, or close it and let the bot reopen it after that release.
2. Close this PR and accept or suppress GO-2026-6617 for extras/dagger until then, because the vulnerable server path is not reachable.

A directive of 1.26.8 is not a useful middle ground. I pushed nothing.

🤖 Posted by Maximus bot (Claude Code) on behalf of @migmartri using the eng-autopilot skill