This PR proposes bumping the pinned Go toolchain to 1.26.6 and google.golang.org/grpc to v1.82.1 so govulncheck passes again. We include this PR work along with a full history of your repo at https://eastagiletracker.com/projects/361. You can sign in with your GitHub ID to claim ownership of the project.

What's broken

The Vulnerability Check job of the Security workflow has been failing on master since the 2026-08-03 scheduled run; the most recent one (run 31981346247, 2026-08-17) exits 3 with seven advisories. The same govulncheck gate runs in release.yml before any binary is built, in all four release jobs (core, sdk, contrib, admin), so a tag pushed today would fail at the vulnerability-check step rather than publish.

Six of the seven are standard-library issues, all fixed in go1.26.6, and all reachable from code that runs in the proxy: GO-2026-6090 (crypto/tls) via proxy.Server.Start and proxy.ForwardProxy.ServeHTTP, GO-2026-6089 and GO-2026-5026 (net/http) via proxy.Server.Serve and httputil.ReverseProxy.RoundTrip, GO-2026-6091 (html/template) via router.AllowListMiddleware.ServeHTTP, GO-2026-5972 (encoding/asn1) via crypto.GenerateServerCSR, and GO-2026-6218 (net/url) via chaperone.exchangeCode. The seventh, GO-2026-6061, is in google.golang.org/grpc v1.81.1 and is fixed in v1.82.1; go mod why -m google.golang.org/grpc resolves it through internal/telemetry and the otlptracehttp exporter, so it is in the live import graph rather than a test-only path.

Reproduction at current HEAD

On master at 8a4338e, with the toolchain your go.mod selects and the govulncheck version your workflow pins:

$ go version
go version go1.26.5 linux/amd64
$ go install golang.org/x/vuln/cmd/govulncheck@v1.1.4
$ govulncheck ./... ; echo "exit=$?"
Vulnerability #1: GO-2026-6218
    Found in: net/url@go1.26.5
    Fixed in: net/url@go1.26.6
...
Vulnerability #7: GO-2026-5026
    Found in: net/http@go1.26.5
    Fixed in: net/http@go1.26.6
exit=3

The sdk, plugins/contrib and admin modules report 1, 4 and 5 of the same advisories respectively, so every module's release job is affected.

The change

The go directive moves from 1.26.5 to 1.26.6 in go.mod, sdk/go.mod, plugins/contrib/go.mod, plugins/contrib/microsoft/keyvault/go.mod, admin/go.mod and go.work — the same set of files, in the same shape, as d8b3d6b (security: bump Go to 1.26.5 to fix stdlib vulnerabilities, #138). Because your workflows resolve the toolchain with go-version-file: go.mod, this is what actually selects the standard library compiled into the released binaries: go version -m bin/chaperone reports go1.26.6 after the change. The indirect google.golang.org/grpc requirement moves to v1.82.1, the version the advisory names, and go mod tidy leaves the rest of the graph untouched — the whole diff is nine lines.

One deliberate trade, since this is your call to make: pinning a patch release in sdk/go.mod raises the minimum toolchain for plugin authors consuming the published SDK. That is the same trade #138 already made, so this keeps your existing convention rather than introducing a new one; if you would rather the SDK float at go 1.26, that line is easy to drop from this PR.

Verification

After the change, govulncheck exits 0 on all four modules, run exactly as security.yml runs them:

$ go version
go version go1.26.6 linux/amd64
$ govulncheck ./... ; echo "exit=$?"
No vulnerabilities found.
exit=0
$ (cd sdk && govulncheck ./...) ; (cd plugins/contrib && govulncheck ./...) ; (cd admin && govulncheck ./...)
No vulnerabilities found.
No vulnerabilities found.
No vulnerabilities found.

That check is the regression test here: it is red on the baseline tree and green on this one, and it is your own gate rather than a new one added by this PR. Since the change alters the compiler for everything, I also ran the rest of your suite on both trees and compared the result sets rather than a pass/fail: go test ./... across the root, sdk, plugins/contrib, plugins/contrib/microsoft/keyvault and admin modules gives 31 packages ok and zero failures before the change and 31 ok and zero failures after, an identical set. All three binaries (chaperone, chaperone-onboard, chaperone-admin) build with CGO_ENABLED=0, and cmd/chaperone cross-compiles cleanly for each platform release.yml targets: linux/amd64, linux/arm64, darwin/amd64, darwin/arm64 and windows/amd64.

Your detect-code-changes action counts go.mod as a code change, so the Security and CI workflows both run on this PR — its own check run is the most direct confirmation available.

How this was managed

This work was tracked as a single story, Bump Go toolchain pin to 1.26.6 and grpc to 1.82.1 to clear the failing vulnerability gate, on a board imported from this repository's own 149 pull requests and its labels, which is also where the reproduction and verification notes above were kept while the fix was in progress.

If you'd rather not receive contributions like this, reply no-more-prs on this pull request and we won't open any further ones on your repositories.

Lawrence W. Sinclair
CEO / East Agile
linkedin.com/in/lwsinclair/
eastagile.com