Bump x/text, quic-go and pgx: three govulncheck findings with call paths in v3.1.1
Author: lbellowsCreated Sep 17, 2026Updated Sep 17, 2026
govulncheck ./... on v3.1.1 reports three vulnerabilities with call paths into the binary:
Vulnerability #1: GO-2026-5970 Infinite loop on invalid input in golang.org/x/text
Found in: golang.org/x/[email protected] Fixed in: golang.org/x/[email protected]
#1: runner/runner.go:154:37: runner.applyLetsEncrypt calls autocert.HostWhitelist, which eventually calls norm.Form.Bytes
#5: database/ping.go:9:19: database.GormDatabase.Ping calls sql.DB.Ping, which eventually calls norm.Form.Span
Vulnerability #2: GO-2026-5676 HTTP/3 QPACK Trailer Expansion Memory Exhaustion in github.com/quic-go/quic-go
Found in: github.com/quic-go/[email protected] Fixed in: github.com/quic-go/[email protected]
Vulnerability #3: GO-2026-5004 SQL Injection via placeholder confusion with dollar quoted string literals in github.com/jackc/pgx
Found in: github.com/jackc/pgx/[email protected] Fixed in: github.com/jackc/pgx/[email protected]
#1: database/database.go:184:13: database.GormDatabase.Close calls sql.DB.Close, which eventually calls sanitize.SanitizeSQLPlus, imported but not called: GO-2026-4772 and GO-2026-4771 (pgx, fixed in 5.9.0), GO-2026-5158 (otel, 1.44.0), GO-2026-4503 (edwards25519, 1.1.1).
None of these look independently exploitable through Gotify as written — the pgx trace is only through Close, and gorm's postgres driver uses the extended protocol rather than the sanitizer — but all three are transitive bumps.
Would renovate.json be expected to pick these up, or is a manual go get -u the intended path here? Happy to send the PR either way.
Source: gotify/server