fix(security): bump pgx/x/net/x/text and raise go.mod floor - #63
fix(security): bump pgx/x/net/x/text and raise go.mod floor#63moizpgedge wants to merge 3 commits into
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.
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).
|
Warning Review limit reached
Next review available in: 23 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (2)
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 |
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.
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.
moizpgedge
changed the title
moizpgedge
changed the title
1 participant
What this fixes
A security scan flagged 23 warnings in this project's dependencies —
2 rated Critical, 12 High. All of them traced back to one thing: a
few outdated open-source libraries and an outdated version of the
underlying programming language itself. Updated all of them to
current, patched versions. No feature changes, no behavior changes.
What was updated
How I checked this actually fixes things
For the language-version update, I didn't just trust the report: I
built the actual program with the old, vulnerable version and
confirmed 6 of the flagged issues were genuinely present and
reachable (things like how it verifies server identity and handles
secure connections, both used every time this service talks to
Kubernetes or the database). Rebuilt with the updated version and
confirmed all 6 were gone.
Also ran the full test suite and the same security scanner against
the updated code: everything passes, and the scan now reports zero
warnings at any severity level.
Relationship to the other open security PR
A separate security scan (Trivy, PR #62) already fixed three of these
same library versions. This PR reuses that exact fix and adds the one
thing that scan didn't separately call out: the language-version
update. Whichever of the two PRs merges first, the other will need a
small follow-up cleanup — not a blocker, just a heads-up.
What this doesn't do
This only updates the source code. The already-published image that
people are currently using was built before this fix and isn't
automatically updated by it — a new version needs to be built and
released separately once this merges.
Fixes PLAT-690.