Any plans for a release including the updated pgx dependency? (CVE-2026-33815 / -33816 / -41889) ?

[tomaszd]

Hi, and thanks for pgmetrics — we package it for our on-prem product and it has been rock solid.
We are hitting a supply-chain issue that we cannot resolve on our side without diverging from your releases, so I wanted to ask about your release plans before we do anything unusual.

The problem

Security scanners flag three CVEs in github.com/jackc/pgx/v5 in the latest tagged release:

CVE	Description	Fixed in pgx
CVE-2026-33815	Memory-safety issue in pgproto3 (Backend.Receive, Bind.Decode)	5.9.0
CVE-2026-33816	Memory-safety issue in pgproto3 (Backend.Receive, FunctionCall.Decode)	5.9.0
CVE-2026-41889	SQL injection via placeholder confusion with dollar-quoted string literals	5.9.2
How the released versions map to pgx:

• v1.18.0 → pgx/v5 v5.7.6 — affected
• v1.19.0 (latest release, Jan 2026) → pgx/v5 v5.8.0 — still affected
• master → pgx/v5 v5.10.0 — clean
  So the fix is already on master (93a19b2, "Update to latest go and build deps", Aug 16), but there is no tagged release that carries it. v1.19.0 predates the pgx patches, so no existing release can contain them.

Reachability analysis, in case it helps prioritisation

We ran govulncheck in source mode against v1.19.0 to see what is actually reachable from pgmetrics code, rather than merely present in the binary:

• CVE-2026-33815 and CVE-2026-33816 are not reachable. The vulnerable symbols live on the server side of the protocol (pgproto3.Backend). The linker keeps them in the binary, so binary-mode scanners report them, but nothing in pgmetrics calls them.
• CVE-2026-41889 is reachable, via the simple-protocol sanitisation path:

  Collect @ github.com/rapidloop/pgmetrics/collector/collect.go:239:23
  getDBNames @ github.com/rapidloop/pgmetrics/collector/collect.go:321:15
    ...
  Conn.Query @ github.com/jackc/pgx/v5/conn.go:856:38
  Conn.sanitizeForSimpleQuery @ github.com/jackc/pgx/v5/conn.go:1272:29
  SanitizeSQL @ github.com/jackc/pgx/v5/internal/sanitize/sanitize.go:433:6
  

We are not claiming this is exploitable in practice — pgmetrics builds its own SQL, and exploitation would need an attacker-controlled placeholder value inside a dollar-quoted literal. But it is enough to keep scanners red and to block us from declaring the package unaffected.
As a check, we rebuilt the v1.19.0 tag with only the dependencies bumped (pgx to 5.10.0, plus golang.org/x/net and golang.org/x/text). It builds with no source changes, and govulncheck then reports zero reachable vulnerabilities, down from four.

The question

Are you planning a release in the near future that would include the updated dependencies?
If the Postgres 19 work currently on master needs more time, would you consider cutting a patch release from the v1.19.0 tag with just the dependency bumps? That would let downstream packagers stay on official release artifacts instead of building from an untagged commit, which is what we would otherwise have to do.
Happy to help with testing or to open a PR if that would be useful. Thanks!

[mdevan]

Hi.

The plan is to release v1.20.0 after testing with Postgres 19 GA release, which makes the v1.20.0 release date dependent on the Postgres 19 release date. Postgres 19 support is being incrementally added to master currently.

So far we did not make a minor release of v1.19 as we concluded that the reported vulnerabilities would not expose the user of pgmetrics to any risk or harm. However, I'm OK with tagging commit 61aa906 as v1.19.1 and making a release. What do you think?

[tomaszd]

I'm fine with that !

If that TAG is a tag for a commit that will pass the sec vulns test and there is no [CVE-2026-33815 / -33816 / -41889] on the code then on it I'm happy with that

Thank you!

[mdevan]

Commit 61aa906 is the one after the commit you referenced (93a19b2). It'll help if you can confirm that the tests pass on 61aa906.

[tomaszd]

Yes, tagging 61aa906 as v1.19.1 would be perfect for us — thank you!

I checked that commit and it looks like a clean, low-risk patch release: it is
v1.19.0 plus exactly two dependency-bump commits (93a19b2 and 61aa906), with no
changes to pgmetrics source and none of the Postgres 19 work.
On the tests: the repository has no test files, so go test ./... passes
trivially ("no test files" for all three packages). To give you something more
meaningful, I ran the following on 61aa906:

• go vet ./... — clean
• build with CGO_ENABLED=0 and -trimpath, using Go 1.25.14 (go.mod asks for
  1.25.13) — clean
• the resulting binary against a PostgreSQL 17.11 instance — correct human
  output and valid JSON output, no errors
• govulncheck ./... (source mode) — 0 reachable vulnerabilities, down from 4
  on v1.19.0
• govulncheck -mode=binary on the built binary — none of CVE-2026-33815,
  CVE-2026-33816 or CVE-2026-41889 present
  The only findings left in binary mode are golang.org/x/crypto/openpgp
  (unmaintained package advisory) and two old github.com/aws/aws-sdk-go s3crypto
  issues. All three have "Fixed in: N/A", so they are not something a release can
  address, and they are equally present in v1.18.0 and v1.19.0 today.
  So from our side 61aa906 is good to tag. Happy to test the release artifacts
  once it is out.

[mdevan]

v1.19.1 is now tagged and released.

[tomaszd]

thank you