fix(security): bump pgx/x/net/x/text and raise go.mod floor to resolve reachable CVEs - #62
Conversation
The published ghcr.io/pgedge/pgedge-helm-utils:v1.0.0 image reported 2 Critical, 5 High, 4 Medium, and 1 Low finding, all Go module or stdlib CVEs (this image's runtime stage is FROM scratch, so there is no OS package layer at all to have findings in). - github.com/jackc/pgx/v5: 5.8.0 -> 5.9.2. Fixes CVE-2026-33815 and CVE-2026-33816 (memory-safety) and, as a bonus not in the original report, GO-2026-5004 (SQL injection via placeholder confusion), which govulncheck shows reachable from internal/spock/replication_slot_advance.go. Confirmed that call site uses bind parameters ($1, $2) and this codebase never sets QueryExecModeSimpleProtocol, so the reachable path isn't actually exploitable as written, but the version bump removes the exposure regardless of future changes to how queries are issued. - golang.org/x/net: 0.47.0 -> 0.56.0. Fixes CVE-2026-25681, CVE-2026-27136, CVE-2026-33814, CVE-2026-39821, and several golang.org/x/net/html and dns/dnsmessage advisories govulncheck found that weren't individually broken out in the report. - golang.org/x/text: 0.31.0 -> 0.39.0. Fixes GO-2026-5970, reachable via the Kubernetes dynamic client's List() call and pgx.ConnectConfig. The reported os.Root symlink CVE (CVE-2026-39822) and remaining Medium/Low findings were stdlib issues in the toolchain used to build the published image; the Dockerfile's builder stage already floats on the "golang:1.25" tag, so a fresh build picks up the current patch release with no Dockerfile change needed. Added .trivy/pgedge-helm-utils.trivyignore.yaml (empty vulnerabilities list) to match the convention in the sibling pgedge-postgres-mcp/pgedge-rag-server repos and give future scans a place to land justified entries; nothing needs suppressing right now. Verified: go build, go vet, go test ./... (all packages), make test-unit (Helm chart template rendering), and helm lint all pass. govulncheck ./... reports no vulnerabilities. Built the image fresh from this branch and ran `trivy image --ignorefile .trivy/pgedge-helm-utils.trivyignore.yaml`: 0 findings at every severity.
📝 WalkthroughWalkthroughThe PR updates the Go version and direct and indirect dependencies in ChangesMaintenance updates
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
.trivy/pgedge-helm-utils.trivyignore.yaml (1)
25-28: 🔒 Security & Privacy | 🔵 Trivial | 🏗️ Heavy liftPin the builder to an exact patched Go image.
Relying on floating
golang:1.25makes the stdlib remediation non-reproducible and prevents the scan result from being tied to a specific toolchain. Pin an exact patched version and preferably its digest, then record that version in the build metadata.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.trivy/pgedge-helm-utils.trivyignore.yaml around lines 25 - 28, Update the Dockerfile builder image reference from floating golang:1.25 to an exact patched Go 1.25 version, preferably including its immutable digest, and ensure the selected version is recorded in the associated build metadata and this Trivy ignore rationale.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.trivy/pgedge-helm-utils.trivyignore.yaml:
- Around line 30-32: Update the verification note in the Trivy ignore file to
avoid claiming the released :v1.0.0 image is clean unless the patched image has
been rebuilt, scanned, and republished. Include the fixed published image digest
in the verification, or explicitly mark the existing released tag as
unremediated.
---
Nitpick comments:
In @.trivy/pgedge-helm-utils.trivyignore.yaml:
- Around line 25-28: Update the Dockerfile builder image reference from floating
golang:1.25 to an exact patched Go 1.25 version, preferably including its
immutable digest, and ensure the selected version is recorded in the associated
build metadata and this Trivy ignore rationale.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: ff772c7f-e483-4d3b-8126-8912897261d1
⛔ Files ignored due to path filters (1)
go.sumis excluded by!**/*.sum
📒 Files selected for processing (2)
.trivy/pgedge-helm-utils.trivyignore.yamlgo.mod
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Duplication | 0 |
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
The published ghcr.io/pgedge/pgedge-helm-utils:v1.0.0 image reported 2 Critical, 5 High, 4 Medium, and 1 Low finding, all Go module or stdlib CVEs (this image's runtime stage is FROM scratch, so there is no OS package layer at all to have findings in). - github.com/jackc/pgx/v5: 5.8.0 -> 5.9.2. Fixes CVE-2026-33815 and CVE-2026-33816 (memory-safety) and, as a bonus not in the original report, GO-2026-5004 (SQL injection via placeholder confusion), which govulncheck shows reachable from internal/spock/replication_slot_advance.go. Confirmed that call site uses bind parameters ($1, $2) and this codebase never sets QueryExecModeSimpleProtocol, so the reachable path isn't actually exploitable as written, but the version bump removes the exposure regardless of future changes to how queries are issued. - golang.org/x/net: 0.47.0 -> 0.56.0. Fixes CVE-2026-25681, CVE-2026-27136, CVE-2026-33814, CVE-2026-39821, and several golang.org/x/net/html and dns/dnsmessage advisories govulncheck found that weren't individually broken out in the report. - golang.org/x/text: 0.31.0 -> 0.39.0. Fixes GO-2026-5970, reachable via the Kubernetes dynamic client's List() call and pgx.ConnectConfig. The reported os.Root symlink CVE (CVE-2026-39822) and remaining Medium/Low findings were stdlib issues in the toolchain used to build the published image; the Dockerfile's builder stage already floats on the "golang:1.25" tag, so a fresh build picks up the current patch release with no Dockerfile change needed. Added .trivy/pgedge-helm-utils.trivyignore.yaml (empty vulnerabilities list) to match the convention in the sibling pgedge-postgres-mcp/pgedge-rag-server repos and give future scans a place to land justified entries; nothing needs suppressing right now. Verified: go build, go vet, go test ./... (all packages), make test-unit (Helm chart template rendering), and helm lint all pass. govulncheck ./... reports no vulnerabilities. Built the image fresh from this branch and ran `trivy image --ignorefile .trivy/pgedge-helm-utils.trivyignore.yaml`: 0 findings at every severity.
The Codacy report lists a batch of stdlib CVEs against go.mod's
declared 1.25.9 floor (net/mail, crypto/x509, net/http/internal/http2,
os.Root, mime, net/textproto, html/template, crypto/tls, net), with
fix versions ranging up to 1.25.12. Confirmed 6 of these genuinely
reachable by building this binary with the actual go1.25.9 toolchain
and running govulncheck in binary mode: crypto/tls handshake,
net/textproto header parsing, mime header decoding, crypto/x509
hostname verification, net.Dialer, and the HTTP/2 transport — this
service does make outbound TLS/HTTP connections (to Kubernetes and
Postgres), so these aren't theoretical. Rebuilding with 1.25.12 drops
that to zero.
Also confirmed the floor is structurally durable, not just true
today: with go.mod now requiring >=1.25.12, the actual go1.25.9
toolchain refuses to build this project at all
("go: go.mod requires go >= 1.25.12").
This is on top of the pgx/x/net/x/text bumps already fixed for the
Trivy triage (PLAT-691, #62) and cherry-picked onto this branch,
which already covered CVE-2026-33815/33816/41889 (pgx),
CVE-2026-25681/27136/39821/42502/42506/25680 (x/net), and
CVE-2026-56852 (x/text) from this same Codacy report.
Verified: go build, go test ./... (all packages), make test-unit all
pass. Rebuilt the full pgedge-helm-utils image from this branch and
ran `trivy image`: 0 findings at every severity, both before and
after this additional floor bump (the dependency versions already
covered the fixable Critical/High; this closes the remaining stdlib
gap Codacy's go.mod-level scan flagged separately).
Addresses CodeRabbit review on #62. The "Verified: 0 findings" note in the ignore file's header comment read as if the vulnerability were fully resolved, without saying that the published ghcr.io/pgedge/pgedge-helm-utils:v1.0.0 tag was built before this fix and is untouched by it. go.mod edits can't retroactively patch an already-pushed image; consumers pinned to :v1.0.0 remain exposed until a new image is built from this fix and released under a new tag. Reworded to say so explicitly, matching what the PR description already says under "Not done here." Reverified after the change: rebuilt the image and rescanned with the updated ignore file, still 0 findings at every severity.
Addresses CodeRabbit review on #62. The "Verified: 0 findings" note in the ignore file's header comment read as if the vulnerability were fully resolved, without saying that the published ghcr.io/pgedge/pgedge-helm-utils:v1.0.0 tag was built before this fix and is untouched by it. go.mod edits can't retroactively patch an already-pushed image; consumers pinned to :v1.0.0 remain exposed until a new image is built from this fix and released under a new tag. Reworded to say so explicitly, matching what the PR description already says under "Not done here." Reverified after the change: rebuilt the image and rescanned with the updated ignore file, still 0 findings at every severity.
…AT-691/Security-Trivy-Triage-security-issues Brings in the go.mod floor bump to 1.25.12 (closes the stdlib CVEs the Codacy triage flagged) on top of the pgx/x/net/x/text bumps this branch already had for the Trivy triage.
What this fixes
A security scan of the published utility image flagged 2 Critical,
5 High, 4 Medium, and 1 Low warnings . This image has no
operating system in it at all (it's built from a completely empty
base), so every warning traced back to one thing: outdated
programming-language dependencies. Updated three of them (
pgx,golang.org/x/net,golang.org/x/text) to their current versions,which resolves every warning in that report, plus a couple of
additional ones an automated code-scanning tool found along the way
that weren't in the original list.
A second, separate scan flagged a batch of Go standard
library CVEs against the
go.modfloor this image's builder stage wasusing —
crypto/tls,net/textproto,mime,crypto/x509,net.Dialer, and the HTTP/2 transport, among others. This servicedoes make outbound TLS/HTTP connections (to Kubernetes and Postgres),
so these aren't theoretical: confirmed 6 of them genuinely reachable
by building with the actual old toolchain and running
govulncheckinbinary mode. Raised the
go.modfloor to the version that fixes allof them; that floor is now also structurally enforced — an older
toolchain refuses to build this project at all rather than silently
building an unpatched binary.
A closer look at one of them
One of the updated libraries had a warning about a way database
queries could potentially be tampered with. Before just trusting the
warning, I checked our own code that uses this library: it always
passes user-supplied values as separate, safely-handled parameters,
never pastes them directly into a query. That specific method of
attack the warning describes doesn't actually apply the way our code
uses it. Still updated the library anyway, since it's free to do and
removes any doubt.
Also added
A tracking file (
.trivy/pgedge-helm-utils.trivyignore.yaml) fordocumenting any future warnings that don't have a fix yet, matching
the same approach already used in other repos. It's currently empty
because everything found so far had a real fix, not just a "checked,
doesn't apply" reason.
How I checked this
govulncheckagainst the actual code (not just reading versionnumbers) before and after: found real, reachable issues before,
zero after.
with and without the ignorefile, plus a repo-level
trivy fsscan:zero findings at every severity, down from 2 Critical, 5 High,
4 Medium, 1 Low.