[Farjaad]

Summary

Fixes GO-2026-6612 (Critical): the HTTP/2 server can refund connection-level flow control twice for the same data, once when a client resets a stream and again when the handler reads the buffered data. A malicious client can use this to bypass MaxReceiveBufferPerConnection.

The bug exists in two places, so both are bumped:

Component	Before	After
golang.org/x/net	v0.57.0	v0.60.0
Go (net/http bundles its own HTTP/2 code)	1.26.4	1.26.9

Other golang.org/x/* modules (crypto, mod, sync, sys, term, text, tools) were bumped transitively by go mod tidy. CI picks up Go 1.26.9 automatically through go-version-file: src/go.mod.

Adds a Security changie entry.

Testing

• govulncheck ./...: 0 vulnerabilities (previously reported GO-2026-6612)
• go build ./... passes
• common unit tests pass
• cmd / e2e tests need a live OpsLevel API token. Locally they fail with 401 Unauthorized both before and after this change, so CI is the real check here.

🤖 Generated with Claude Code

[Farjaad]

Why this is safe to merge

1. Only dependency versions change. The diff touches src/go.mod and src/go.sum, plus a changelog entry. No application code changed.

2. The Go bump is a patch release (1.26.4 → 1.26.9). Go patch releases only contain security and bug fixes. They don't change the language or break APIs, and we're staying on the 1.26 line we already moved to in #423.

3. The golang.org/x/* bumps are small. Every one is a minor version step within v0.x: x/net 0.57→0.60, the rest by 1–3 minor versions. They're all indirect dependencies we don't import directly, and go mod tidy picked them because x/net v0.60.0 requires them.

4. Our own exposure to this CVE is low. GO-2026-6612 is in the HTTP/2 server. The CLI is an HTTP client: there's no ListenAndServe, http.Server, or http2.Server in src/. So this bump is mostly about clearing the scanner finding, not fixing a live attack path. That also means the code paths that changed upstream are ones we barely use.

5. Verification

• ✅ CI test job, which runs on Go 1.26.9 via go-version-file: gofumpt, go vet, golangci-lint, and common tests with -race
• ✅ CodeQL (go + actions)
• ✅ govulncheck ./...: 0 vulnerabilities (was reporting GO-2026-6612)
• ✅ Local smoke test of the built binary: opslevel version, --help, and subcommand help all work

Not covered: CI doesn't run the cmd integration tests or the e2e tests on PRs, because they need a live OpsLevel API token. Locally they fail with 401 Unauthorized both on main and on this branch, so that's an environment issue, not a regression. If you want extra confidence, run task test-integration with a token before merging.

Rollback: if anything comes up, reverting this single commit fully restores the previous versions.

[Farjaad]

Update: integration and e2e tests pass

Following up on the "Not covered" note above: I ran both token-gated suites locally on this branch (Go 1.26.9, x/net v0.60.0) against a non-production demo account.

• ✅ e2e tests (go test -v ./e2e/...), 5/5 pass: Domain, Infrastructure, Service, System, Team. Each runs the full cycle: create, get, list, update, get, delete, then confirms the resource is gone.
• ✅ cmd integration tests (go test -race ./cmd/...), 2/2 pass: Test_TeamCRUD, Test_UserCRUD
• ✅ Checked the account after the run: the tests left no resources behind.

All verification is now done: CI, CodeQL, govulncheck, a smoke test of the built binary, and the integration and e2e suites.