security: 7 reachable govulncheck findings - 6 stdlib (fixed in go1.26.6) + GO-2026-6222 in golang.org/x/image

[PierrunoYT]

Ran govulncheck ./... against current main (980f2f4, go 1.26.5 in 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 in golang.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 the go/toolchain directive plus one dependency bump, then re-running make vulncheck.

Standard library (fixed in go1.26.6)

GO-2026-6218 - quadratic complexity in net/url resolvePath

• internal/tools/web_search.go:266 - httpSearchBackend.Search -> http.Client.Do -> url.URL.Parse
• internal/mcp/network_client.go:736 - resolveSSEEndpointURL -> url.URL.ResolveReference

GO-2026-6090 - unbounded post-handshake messages in crypto/tls

• internal/mcp/oauth.go:430 - Login -> http.Server.Serve -> tls.Conn.HandshakeContext
• internal/dictation/download.go:722 - progressReader.Read -> tls.Conn.Read
• internal/daemon/protocol.go:64 - WriteFrame -> tls.Conn.Write
• internal/daemon/remote/client.go:79 - dialAuthenticated -> tls.Dialer.DialContext

GO-2026-6089 - ReadHeaderTimeout not applied during the unencrypted HTTP/2 check in net/http

• internal/mcp/oauth.go:430 - Login -> http.Server.Serve

GO-2026-6088 - missing recursion depth guard in encoding/xml

• internal/daemon/pool.go:326 - Pool.Drain -> xml.Decoder.Decode
• internal/tui/syntax_highlight.go:11 - lexers.init -> xml.Decoder.DecodeElement / xml.Decoder.Token

GO-2026-5972 - no maximum recursion depth in encoding/asn1

• internal/daemon/remote/bridge.go:250 - ServerTLSConfig -> tls.LoadX509KeyPair -> asn1.Unmarshal

GO-2026-5026 - ASCII-only Punycode-encoded labels not rejected in golang.org/x/net/idna (vendored in stdlib net/http)

• internal/tools/web_search.go:266, internal/mcp/network_client.go:782

All six resolve by moving the go directive to 1.26.6.

Module dependency (fixed in v0.45.0)

GO-2026-6222 - excessive memory allocation during VP8L decoding in golang.org/x/image

• internal/terminalpet/client.go:738 - decodeImage -> image.Decode -> vp8l.Decode

Resolves with go get golang.org/x/image@v0.45.0 and go 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

1. Bump go in go.mod to 1.26.6 (no toolchain line is currently pinned).
2. go get golang.org/x/image@v0.45.0 && go mod tidy.
3. Re-run make fmt-check, go vet ./..., go test ./..., make vulncheck per AGENTS.md validation.

Happy to open the PR if the approach sounds right.

[PierrunoYT]

Status check against current main (dc15e822):

Partially fixed.

✅ Standard library (6 findings) — resolved

PR #903 bumped go in go.mod to 1.26.6 (commit dc15e822). Re-running govulncheck with GOTOOLCHAIN=go1.26.6 shows 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 present

go.mod still pins golang.org/x/image v0.44.0. Verified with go 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

1. go get golang.org/x/image@v0.45.0 && go mod tidy
2. 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.

[Vasanthdev2004]

@PierrunoYT hold off on that dependency PR, it landed while nobody was looking.

golang.org/x/image went to v0.45.0 on main this morning, inside #902 rather than as a standalone bump, which is why your status check on dc15e822 still 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.decodeImage is 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.

[gnanam1990]

This appears to be fully resolved on main — recommending close.

Verified against origin/main rather 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/main now
go directive	1.26.5	1.26.6
golang.org/x/image	v0.44.0	v0.45.0

Both 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, and x/image is already at the v0.45.0 that 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 the 1.26.6 directive 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/toolchain directive plus one dependency bump rather than for CI pins to be bumped blindly, and that is precisely what happened.