Repository navigation
security: 7 reachable govulncheck findings - 6 stdlib (fixed in go1.26.6) + GO-2026-6222 in golang.org/x/image #907
Description
Activity
Status check against current
main(dc15e822):Partially fixed.
✅ Standard library (6 findings) — resolved
PR #903 bumped
goingo.modto1.26.6(commitdc15e822). Re-running govulncheck withGOTOOLCHAIN=go1.26.6shows zero stdlib findings — GO-2026-6218, GO-2026-6090, GO-2026-6089, GO-2026-6088, GO-2026-5972, and GO-2026-5026 are all gone.❌ GO-2026-6222 (
golang.org/x/image) — still presentgo.modstill pinsgolang.org/x/image v0.44.0. Verified withgo run golang.org/x/vuln/cmd/govulncheck@v1.3.0 ./...:=== Symbol Results === Vulnerability #1: GO-2026-6222 Excessive memory allocation during VP8L decoding in golang.org/x/image More info: https://pkg.go.dev/vuln/GO-2026-6222 Module: golang.org/x/image Found in: golang.org/x/image@v0.44.0 Fixed in: golang.org/x/image@v0.45.0 Example traces found: #1: internal/terminalpet/client.go:738:36: terminalpet.decodeImage calls image.Decode, which eventually calls vp8l.Decode Your code is affected by 1 vulnerability from 1 module.Remaining work
go get golang.org/x/image@v0.45.0 && go mod tidy- Re-run validation per AGENTS.md (
make fmt-check,go vet ./...,go test ./...,make vulncheck)
Still happy to open that PR for the dependency bump.
@PierrunoYT hold off on that dependency PR, it landed while nobody was looking.
golang.org/x/imagewent to v0.45.0 onmainthis morning, inside #902 rather than as a standalone bump, which is why your status check ondc15e822still saw v0.44.0. Between that and #903 for the stdlib, all seven findings are gone.Verified on current
main(d065467c) with the pinned checker rather than by reading go.mod:go run golang.org/x/vuln/cmd/govulncheck@v1.3.0 ./... No vulnerabilities found.So this is fully resolved, and the reachable VP8L trace through
terminalpet.decodeImageis closed with it.Thanks for the status check on the 14th. Splitting it into resolved-versus-remaining is what made it obvious that the stdlib half and the module half needed different fixes, and it is the reason the second one did not sit unnoticed for another week.
Closing unless you spot something the checker misses.
This appears to be fully resolved on
main— recommending close.Verified against
origin/mainrather than a stale checkout (my working branch was 39 commits behind and initially showed the old values, which is worth flagging since it is an easy way to mis-verify this one):when filed ( 980f2f42)origin/mainnowgodirective1.26.51.26.6golang.org/x/imagev0.44.0v0.45.0Both are exactly the fixed versions this issue names. The Go bump landed in
dc15e822— "fix: bump Go to 1.26.6 for stdlib vulnerability fixes (#903)" — which covers all six stdlib findings, andx/imageis already at thev0.45.0that fixes GO-2026-6222.Ran the pinned checker from
AGENTS.md:go run golang.org/x/vuln/cmd/govulncheck@v1.3.0 ./... No vulnerabilities found.Also confirmed the fix propagates to CI rather than only locally: every workflow resolves its toolchain with
go-version-file: go.mod(ci.yml:30,100,130,pr-auto-review.yml:31,release-artifacts.yml:47), so the1.26.6directive is what CI builds with.Worth noting the issue's framing was right and is what made it easy to close: it asked for the
go/toolchaindirective plus one dependency bump rather than for CI pins to be bumped blindly, and that is precisely what happened.
Ran
govulncheck ./...against currentmain(980f2f4,go 1.26.5in go.mod,golang.org/x/image v0.44.0). 7 reachable vulnerabilities: 6 in the standard library (all fixed in go1.26.6) and 1 ingolang.org/x/image(fixed in v0.45.0).Not a request to bump CI pins blindly: per AGENTS.md the toolchain version is declared in
go.mod, so the fix is thego/toolchaindirective plus one dependency bump, then re-runningmake vulncheck.Standard library (fixed in go1.26.6)
GO-2026-6218 - quadratic complexity in
net/urlresolvePathinternal/tools/web_search.go:266-httpSearchBackend.Search->http.Client.Do->url.URL.Parseinternal/mcp/network_client.go:736-resolveSSEEndpointURL->url.URL.ResolveReferenceGO-2026-6090 - unbounded post-handshake messages in
crypto/tlsinternal/mcp/oauth.go:430-Login->http.Server.Serve->tls.Conn.HandshakeContextinternal/dictation/download.go:722-progressReader.Read->tls.Conn.Readinternal/daemon/protocol.go:64-WriteFrame->tls.Conn.Writeinternal/daemon/remote/client.go:79-dialAuthenticated->tls.Dialer.DialContextGO-2026-6089 -
ReadHeaderTimeoutnot applied during the unencrypted HTTP/2 check innet/httpinternal/mcp/oauth.go:430-Login->http.Server.ServeGO-2026-6088 - missing recursion depth guard in
encoding/xmlinternal/daemon/pool.go:326-Pool.Drain->xml.Decoder.Decodeinternal/tui/syntax_highlight.go:11-lexers.init->xml.Decoder.DecodeElement/xml.Decoder.TokenGO-2026-5972 - no maximum recursion depth in
encoding/asn1internal/daemon/remote/bridge.go:250-ServerTLSConfig->tls.LoadX509KeyPair->asn1.UnmarshalGO-2026-5026 - ASCII-only Punycode-encoded labels not rejected in
golang.org/x/net/idna(vendored in stdlibnet/http)internal/tools/web_search.go:266,internal/mcp/network_client.go:782All six resolve by moving the
godirective to 1.26.6.Module dependency (fixed in v0.45.0)
GO-2026-6222 - excessive memory allocation during VP8L decoding in
golang.org/x/imageinternal/terminalpet/client.go:738-decodeImage->image.Decode->vp8l.DecodeResolves with
go get golang.org/x/image@v0.45.0andgo mod tidy.govulncheck also reported 2 unreachable findings (1 imported package, 1 required module); those do not affect callers and are not listed here. Full output available with
go run golang.org/x/vuln/cmd/govulncheck@v1.3.0 ./...once built with a >= 1.26.6 toolchain.Proposed fix
goingo.modto 1.26.6 (notoolchainline is currently pinned).go get golang.org/x/image@v0.45.0 && go mod tidy.make fmt-check,go vet ./...,go test ./...,make vulncheckper AGENTS.md validation.Happy to open the PR if the approach sounds right.