security: bump golang.org/x/net to v0.57.0 and klauspost/compress to v1.18.7

[nitinpunn-attention]

Summary

Closes the one open Dependabot alert, plus 23 further advisories that Dependabot never raised, by moving golang.org/x/net to v0.57.0 and github.com/klauspost/compress to v1.18.7. Only go.mod and go.sum change. There are no application-code changes.

Two things a reviewer should read before anything else:

1. Dependabot's floor of 0.55.0 for golang.org/x/net is not sufficient. GO-2026-5942 (CVE-2026-46600) is fixed only in 0.56.0 and has no GHSA record, so it generates no alert. The existing dependabot/go_modules/golang.org/x/net-0.55.0 branch would leave it open.
2. The go directive moves from 1.24.0 to 1.25.0, and that is forced, not chosen. Details and consumer impact are in their own section below. This repository is a public Go module, so that change is visible downstream.

Baseline and freshness

Baseline commit	675144ba5114a6777a28bc86f11db3c708d5ad93 (fetched origin/main, 2026-08-08)
Local clone staleness	0 behind, 0 ahead. git rev-list --left-right --count main...origin/main returned 0 0. Branch was cut from the freshly fetched origin/main, not from local HEAD
Working tree at start	clean (git status --porcelain empty)
Alert data	pulled fresh in this session via gh api repos/attentiontech/walstream-go/dependabot/alerts?state=open. No inherited inventory was used
Toolchain	go1.26.3 darwin/arm64, GOPROXY https://proxy.golang.org,direct, GOFLAGS empty

Note: tag v0.3.0 points at 675144b, so main is the currently released version. No tag was created or pushed by this change, and none should be until a maintainer decides to cut a release.

Alert-by-alert disposition

Open Dependabot alerts at baseline: 1 medium, 0 low, 0 high, 0 critical.

Alert	Advisory	Package	Installed	Disposition
#1	GHSA-5cv4-jp36-h3mw / CVE-2026-25680 / GO-2026-5028, medium, CVSS 6.5	golang.org/x/net (transitive, go.mod, runtime scope)	0.49.0, vulnerable range < 0.55.0	Resolved. Now 0.57.0

The advisory was checked for withdrawn_at (null) and its full vulnerabilities list was read (one entry, no other package mapping).

Applicability note, stated in both directions so it is not overread or underread: the affected import path is golang.org/x/net/html, and no golang.org/x/net package is compiled by this module. go list -deps -test ./... returns zero packages under golang.org/x/net, and go mod why golang.org/x/net/html returns "main module does not need package golang.org/x/net/html". go mod why -m golang.org/x/net shows the requirement exists only because github.com/segmentio/kafka-go's own test binary imports golang.org/x/net/nettest. The fix still matters because this is a public library: its go.mod is a minimum-version floor for every downstream consumer under MVS, and at 0.49.0 this module was actively holding consumers down onto a vulnerable x/net.

Advisories Dependabot did not raise (found by graph sweep)

Spec-mandated sweep of the whole resolved graph, not just the alert list. Sources: GitHub /advisories?ecosystem=go&affects=..., OSV /v1/query, and the Go vulnerability database (vuln.go.dev index plus per-ID records). Module paths and package import paths and every intermediate prefix were swept, because Go advisories are frequently keyed to package paths that a module-path-only query misses.

Coverage: 20 of 20 module/version pairs in the baseline build list (100 percent), 91 distinct sweep queries, 72 compiled external packages enumerated.

Baseline: 25 distinct applicable advisories. Only 1 of them had an alert.

Module @ baseline	Advisories applicable	Raised by Dependabot	Fixed in
golang.org/x/net v0.49.0	8	1	0.56.0 clears all 8
golang.org/x/crypto v0.47.0	13 (7 critical, 2 high, 4 medium) plus 1 informational	0	0.52.0 clears all 13
github.com/klauspost/compress v1.18.0	1	0	1.18.7
golang.org/x/sys v0.40.0	1	0	0.44.0
golang.org/x/text v0.34.0	1	0	0.39.0

golang.org/x/net v0.49.0 detail: GO-2026-4918 (http2), GO-2026-5025 / 5027 / 5028 / 5029 / 5030 (html), GO-2026-5026 (idna), GO-2026-5942 (dns/dnsmessage).

golang.org/x/crypto v0.47.0 detail, all fixed in 0.52.0, all ssh, ssh/agent or ssh/knownhosts: GHSA-jppx-rxg9-jmrx, GHSA-f5wc-c3c7-36mc, GHSA-vgwf-h737-ff37, GHSA-rm3j-f69w-wqmq, GHSA-89gr-r52h-f8rx, GHSA-5cgq-3rg8-m6cv, GHSA-x527-x647-q7gg (critical); GHSA-q4h4-gmj2-qvw2, GHSA-w879-237q-wc7r (high); GHSA-45gg-vh54-h5m9, GHSA-78mq-xcr3-xm33, GHSA-qpw4-5x99-6vjp, GHSA-9m57-25v3-79x9 (medium).

github.com/klauspost/compress GO-2026-5841 / GHSA-259r-337f-4rfw, range >= 1.16.0, < 1.18.7, affected import github.com/klauspost/compress/s2, symbol s2.NewDict. This is the only baseline finding whose affected package is actually compiled into this module (via kafka-go/compress/snappy). gh api /advisories/GHSA-259r-337f-4rfw returns HTTP 404 and affects=github.com/klauspost/compress returns 0 records, so I could not find this advisory in GitHub's global advisory database on 2026-08-08, which is consistent with no alert being filed. OSV, the Go vulnerability database, and govulncheck all carry it.

Dependency changes

Module	Before	After	Direct or indirect	Reason
golang.org/x/net	v0.49.0	v0.57.0	indirect (explicit in go.mod)	Alert #1 plus 7 unraised advisories
github.com/klauspost/compress	v1.18.0	v1.18.7	indirect (explicit in go.mod)	GO-2026-5841, affected package is compiled
golang.org/x/crypto	v0.47.0	v0.54.0	graph only, not in go.mod	Cascades from x/net. Clears 13 advisories
golang.org/x/sys	v0.40.0	v0.47.0	graph only	Cascades from x/net. Clears GO-2026-5024
golang.org/x/term	v0.39.0	v0.45.0	graph only	Cascades from x/net. No advisory either way
golang.org/x/text	v0.34.0	v0.40.0	graph only after tidy	Cascades from x/net. Clears GO-2026-5970
golang.org/x/mod, golang.org/x/sync, golang.org/x/tools	v0.32.0, v0.19.0, v0.41.0	pruned out of the build list	graph only	Consequence of x/text no longer being a root requirement
go directive	1.24.0	1.25.0	n/a	Forced. See below

No module was downgraded. Every entry in the resolved build list stayed equal, went up, or was pruned out. Verified by comparing go list -m all before and after with a semver comparator.

Not changed, deliberately: github.com/segmentio/kafka-go stays at v0.4.50 (v0.4.51 exists, released 2026-04-23) and github.com/pierrec/lz4/v4 stays at v4.1.15. Neither carries an applicable advisory, both are compiled into the runtime path, and this repository has no test that exercises a Kafka broker or a compression round trip. Bundling them would add behavioral risk with no security benefit.

Version selection rationale

golang.org/x/net v0.57.0, which is the latest stable release (2026-07-08, one month old at time of writing). Measured advisory exposure per candidate, scored against GHSA and OSV with an evaluator that reads the full event list:

Candidate	Applicable advisories
v0.38.0 (kafka-go's own floor)	12
v0.49.0 (baseline)	10
v0.55.0 (Dependabot's proposal)	1: GO-2026-5942 remains open
v0.56.0	0
v0.57.0 (chosen)	0

v0.56.0 would have been sufficient. v0.57.0 was taken per the latest-stable-in-the-maintained-major rule, after confirming it introduces nothing new, that it is not a prerelease, that golang.org/x/net carries no retractions, and that it is a month old rather than days old.

github.com/klauspost/compress v1.18.7, which is deliberately NOT the latest stable. This is a departure from the default and the reason is specific. v1.18.7's release notes read in full: "Fix s2.NewDict OOB read. Security release without other changes." The v1.19.x line, by contrast, added true concurrent zstd stream encoding, new arm64 decoder assembly for zstd and huff0, flate inflate checkpoints, and several zstd dictionary changes. v1.19.2, released three days ago on 2026-08-05, is itself fixing "arm64 asm frame offsets placing locals on the saved LR slot" in that new assembly and re-enabling "unsafe decodeSync memory copies". This module compiles zstd, huff0, flate, s2 and snappy through kafka-go, and has zero tests covering any of them, so a three-day-old minor carrying newly-fixed stack-frame bugs in hand-tuned assembly is a worse trade than the pure security patch. v1.18.7 is the last release on the 1.18 line and carries no known advisory. v1.19.x also carries no known advisory per OSV, so upgrading further later is a clean follow-up whenever there is test coverage to justify it.

No major version upgrades were performed, so no migration guide applies.

The go directive change, and what it means for consumers

go 1.24.0 becomes go 1.25.0. This is not a stylistic bump.

It is forced. go mod tidy -go=1.24.0 with x/net v0.57.0 required exits 1 with:

go: golang.org/x/net@v0.57.0 requires go@1.25.0, but 1.24.0 is requested

I fetched the .mod file of every release that fixes any of these advisories from proxy.golang.org on 2026-08-08, and every one of them declares go 1.25.0: x/net 0.55.0 / 0.56.0 / 0.57.0, x/crypto 0.51.0 through 0.54.0, x/text 0.38.0 through 0.40.0, x/sys 0.43.0 through 0.47.0. Across those candidates I could not find a remediation path that keeps go 1.24.0.

GODEBUG baseline. Crossing from 1.24 into 1.25 flips exactly five settings, read from /usr/local/go/src/internal/godebugs/table.go (entries with Changed: 25):

Setting	Package	Old default	Effect of the flip
containermaxprocs	runtime	0	GOMAXPROCS now derived from cgroup CPU limits
updatemaxprocs	runtime	0	GOMAXPROCS now updated when the limit changes
decoratemappings	runtime	0	anonymous memory mappings annotated (opaque)
tlssha1	crypto/tls	1	SHA-1 signature algorithms rejected in TLS 1.2
x509sha256skid	crypto/x509	0	SHA-256 based subject key identifiers

GODEBUG defaults are taken from the main module's go directive, so for a program that merely imports this library the consumer's own directive governs, not this one. These flips therefore bind this repository's own test and tool builds directly.

But it does reach consumers indirectly, and I measured it. A synthetic consumer module declaring go 1.24.0:

• against baseline walstream-go: go build ./... exits 0 and the consumer's go.mod is untouched
• against this branch: go build ./... in the default readonly mode exits 1 with go: updates to go.mod needed; to update it: go mod tidy, and under -mod=mod it succeeds but rewrites the consumer's own go 1.24.0 to go 1.25.0, which then flips those five settings for the consumer

So consumers on go 1.24 will have to move to go 1.25. Context for that ask: https://go.dev/doc/devel/release states "Each major Go release is supported until there are two newer major releases", Go 1.26.0 was released 2026-02-10, and https://go.dev/dl/?mode=json lists go1.26.5 and go1.25.12 as the current stable releases as of 2026-08-08. Go 1.24 is therefore already outside the supported window and Go 1.25 is inside it.

I did not add godebug directives to pin containermaxprocs or updatemaxprocs. godebug lines only take effect in the main module's go.mod, so in a library they would be inert for every consumer while silently changing only this repository's own test runs. Flagging the flip is the honest action here; pinning it would look like a mitigation without being one. If maintainers want the pin for this repository's own builds, that is a deliberate follow-up decision, not something to smuggle into a dependency bump.

Application-code changes

None. Risk tier: not applicable. git diff --stat is go.mod | 7 +++---- and go.sum | 12 ++++++------.

Validation

Every command was run bare with its output redirected to a file and its exit status captured on the next statement. Nothing below is derived from a pipeline.

Command	Exit	Result
go mod verify	0	all modules verified
go mod tidy -diff	0	0 lines of output
go build ./...	0	no output
go vet ./...	0	no output
go test ./... -count=1	0	streaming ok 1.283s, streaming/types ok 1.358s, 3 packages have no test files
go test -race ./... -count=1	0	streaming ok 1.857s, streaming/types ok 1.217s
gofmt -l .	0	0 lines
git status --porcelain	n/a	M go.mod, M go.sum only

Pre-existing failures: none. The identical command set was run first against a pristine git archive extract of 675144b into an empty directory, and all of it was green there too, including go mod tidy -diff at 0 lines. Baselines were taken from that extract rather than from a working tree that tools had already touched.

govulncheck (~/go/bin/govulncheck v1.6.0, database snapshot 2026-07-27, which was 12 days stale on the day of this run, hence the GHSA and OSV cross-checks above):

	Before	After
Symbol results (called)	3, all Go standard library attributable to the scanning toolchain go1.26.3	same 3, unchanged
Package results (imported, not called)	3: GO-2026-5841 klauspost/compress v1.18.0, plus mime and os from the toolchain	2: mime and os only
Module results	0	No other vulnerabilities found.

The three called findings are GO-2026-5856 crypto/tls (fixed go1.26.5), GO-2026-5039 net/textproto (fixed go1.26.4) and GO-2026-5037 crypto/x509 (fixed go1.26.4). They are properties of the toolchain that ran the scan, not of anything in go.mod, they are identical before and after, and no dependency change can clear them. They are cleared by building with go1.26.4 or newer. Reported here rather than omitted.

After the change govulncheck reports the modules it scanned as walstream-go, klauspost/compress@v1.18.7, lz4/v4@v4.1.15 and kafka-go@v0.4.50. x/net and x/crypto are absent from that list, which independently corroborates that no package from either is built.

Projected remaining applicable vulnerabilities

Full sweep of the proposed graph: 17 of 17 module/version pairs checked (100 percent), 88 distinct queries.

25 distinct applicable advisories at baseline, 1 remaining.

The remaining one is GO-2026-5932, "The golang.org/x/crypto/openpgp package is unmaintained, unsafe by design, and has known security issues". Its OSV range is events: [{"introduced": "0"}] with no fixed event, so as recorded on 2026-08-08 it applies to every published version of golang.org/x/crypto, and I could not find a version that clears it. Its affected import paths (golang.org/x/crypto/openpgp and friends) do not appear in go list -deps -test ./..., so it is not applicable at package level in this repository. It is reported, not counted as resolved and not suppressed.

Reviewer focus

1. The go directive. This is the one judgment call that a maintainer should confirm rather than a reviewer rubber-stamp. It is forced by the fix, it is consumer-visible, and it flips five GODEBUG defaults for anyone whose own go.mod gets rewritten to 1.25.0.
2. go mod tidy dropped the explicit golang.org/x/text v0.34.0 // indirect line, because once x/net v0.57.0 supplies a higher requirement no explicit entry is needed. Inside this repository x/text rises from v0.34.0 to v0.40.0, which clears GO-2026-5970. For a downstream consumer that imports golang.org/x/text and pins nothing itself, I measured the floor this module imposes dropping from v0.34.0 to v0.23.0. That is not a new advisory: v0.23.0 and v0.34.0 carry exactly the same single applicable advisory (GO-2026-5970, fixed 0.39.0), so exposure is unchanged. It is still a floor reduction and worth a maintainer's opinion. I did not hand-add the requirement back because go mod tidy strips it again, which would make go mod tidy -diff red.
3. klauspost/compress v1.18.7 instead of v1.19.2. Deliberate, reasoned above. Reject it if you would rather take the latest, but please do so knowing the arm64 assembly in v1.19.x had a stack-frame bug fixed three days ago and nothing in this repository's test suite would catch a regression there.
4. Close the stale Dependabot branch. dependabot/go_modules/golang.org/x/net-0.55.0 proposes a version that leaves GO-2026-5942 open.

Unrun validation and remaining uncertainty

• I could not find any repository-authored workflow file at 675144b on 2026-08-08. git ls-tree -r origin/main returns no path beginning with .github, gh api .../contents/.github/dependabot.yml returns HTTP 404, and gh api .../actions/workflows returns only the two GitHub-generated dynamic Dependabot workflows. On that evidence, opening this pull request runs no repository-authored CI, there is nothing tag-triggered in this repository, and every claim in this description comes from a command run locally.
• There are no integration tests. streaming and streaming/types are covered; client, streaming/kafka and types have no test files. Nothing exercises a live Kafka broker, TLS, SASL or a compression round trip. The klauspost/compress bump touches code that is compiled but never executed by any test in this repository. That is the largest unmeasured surface in this change.
• Behavior on non-arm64 and non-darwin platforms was not exercised. All runs were go1.26.3 darwin/arm64.
• The Go vulnerability database snapshot used by govulncheck was 12 days old. GHSA and OSV were queried live on 2026-08-08 to compensate, and OSV is the source that carries GO-2026-5942 and GO-2026-5841.
• Absence of a finding in any single database is evidence about that database on that date, not a property of the code.

Rollback

git revert the single commit, or restore go.mod and go.sum from 675144b. There are no application-code changes, no generated files, no vendored tree and no lockfile beyond go.sum, so revert is complete and total. A consumer whose own go.mod was rewritten to go 1.25.0 by building against this branch will not be reverted automatically and would need to lower its own directive by hand.

Branch protection context

main is governed by an active repository ruleset (id 15087352) requiring a pull request with 1 approving review, dismissing stale reviews on push, and blocking deletion and non-fast-forward pushes. The classic /branches/main/protection endpoint returns 404, which is not evidence that the branch is unprotected. No ruleset applies to this branch.