chore(deps): bump github.com/jackc/pgx/v5 from 5.6.0 to 5.9.2

[dependabot]

Bumps github.com/jackc/pgx/v5 from 5.6.0 to 5.9.2.

Changelog

Sourced from github.com/jackc/pgx/v5's changelog.

5.9.2 (April 18, 2026)

Fix SQL Injection via placeholder confusion with dollar quoted string literals (GHSA-j88v-2chj-qfwx)

SQL injection can occur when:

1. The non-default simple protocol is used.
2. A dollar quoted string literal is used in the SQL query.
3. That query contains text that would be would be interpreted outside as a placeholder outside of a string literal.
4. The value of that placeholder is controllable by the attacker.

e.g.

attackValue := `$tag$; drop table canary; --`
_, err = tx.Exec(ctx, `select $tag$ $1 $tag$, $1`, pgx.QueryExecModeSimpleProtocol, attackValue)

This is unlikely to occur outside of a contrived scenario.

5.9.1 (March 22, 2026)

• Fix: batch result format corruption when using cached prepared statements (reported by Dirkjan Bussink)

5.9.0 (March 21, 2026)

This release includes a number of new features such as SCRAM-SHA-256-PLUS support, OAuth authentication support, and PostgreSQL protocol 3.2 support.

It significantly reduces the amount of network traffic when using prepared statements (which are used automatically by default) by avoiding unnecessary Describe Portal messages. This also reduces local memory usage.

It also includes multiple fixes for potential DoS due to panic or OOM if connected to a malicious server that sends deliberately malformed messages.

• Require Go 1.25+
• Add SCRAM-SHA-256-PLUS support (Adam Brightwell)
• Add OAuth authentication support for PostgreSQL 18 (David Schneider)
• Add PostgreSQL protocol 3.2 support (Dirkjan Bussink)
• Add tsvector type support (Adam Brightwell)
• Skip Describe Portal for cached prepared statements reducing network round trips
• Make LoadTypes query easier to support on "postgres-like" servers (Jelte Fennema-Nio)
• Default empty user to current OS user matching libpq behavior (ShivangSrivastava)
• Optimize LRU statement cache with custom linked list and node pooling (Mathias Bogaert)
• Optimize date scanning by replacing regex with manual parsing (Mathias Bogaert)
• Optimize pgio append/set functions with direct byte shifts (Mathias Bogaert)
• Make RowsAffected faster (Abhishek Chanda)
• Fix: Pipeline.Close panic when server sends multiple FATAL errors (Varun Chawla)
• Fix: ContextWatcher goroutine leak (Hank Donnay)
• Fix: stdlib discard connections with open transactions in ResetSession (Jeremy Schneider)

... (truncated)

Commits

• 0aeabbc Release v5.9.2
• 60644f8 Fix SQL sanitizer bugs with dollar-quoted strings and placeholder overflow
• a5680bc Merge pull request #2531 from dolmen-go/godoc-add-links
• e34e452 doc: Add godoc links
• 08c9bb1 Fix Stringer types encoded as text instead of numeric value in composite fields
• 96b4dbd Remove unstable test
• acf88e0 Merge pull request #2526 from abrightwell/abrightwell-min-proto
• 2f81f1f Update max_protocol_version and min_protocol_version defaults
• 4e4eaed Release v5.9.1
• 6273188 Fix batch result format corruption when using cached prepared statements
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  You can disable automated security fix PRs for this repo from the Security Alerts page.

[Lutherwaves]

@CodeRabbit review for any risks

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

Let me inspect the codebase to assess the risks properly.

---

🏁 Script executed:

#!/bin/bash
# Check Go version requirement in go.mod
cat go.mod

echo "---"
# Check how pgx is used in the codebase
rg -n --type=go 'pgx|pgxpool|QueryExecMode|SimpleProtocol|Batch|SendBatch' -C2

Length of output: 5381

---

Let me dig deeper into the SQL usage patterns.

---

🏁 Script executed:

#!/bin/bash
# Read full sql.go
cat storage/sql.go

echo "==="
# Look for any raw SQL queries with dollar signs (potential injection surface)
rg -n --type=go '\$[0-9]|\$[a-zA-Z]|dollar|Exec\(|Raw\(' -C3

echo "==="
# Check gorm postgres driver version (the bridge between gorm and pgx)
grep -i 'gorm.io/driver/postgres' go.mod go.sum | head -10

Length of output: 26114

---

@Lutherwaves: Here's a thorough risk assessment of this bump from pgx v5.6.0 → v5.9.2.

---

Risk Assessment: github.com/jackc/pgx/v5 5.6.0 → 5.9.2

✅ No Risk: Go 1.25 Requirement (v5.9.0)

Your go.mod already declares go 1.25.0, so the new minimum Go version constraint introduced in v5.9.0 is already satisfied. No action needed.

---

✅ No Risk: Batch Result Corruption (v5.9.1)

The codebase has no direct use of pgx batch operations (SendBatch, etc.). pgx is consumed through GORM as an abstraction layer, and GORM does not use pgx batching. The v5.9.1 fix is not applicable here.

---

⚠️ Low Risk (Mitigated by Upgrade): SQL Injection via Dollar-Quoted Strings — GHSA-j88v-2chj-qfwx (v5.9.2)

This vulnerability requires all four conditions simultaneously:

1. Simple protocol in use — MET: storage/sql.go:72 sets PreferSimpleProtocol: true
2. A dollar-quoted string literal in the SQL (e.g., $tag$...$tag$) — NOT found in the codebase
3. A placeholder appearing inside the literal — NOT found
4. Attacker-controlled placeholder value — NOT applicable

The GORM docs document PreferSimpleProtocol: true as the flag that "disables implicit prepared statement usage" — by default pgx uses the extended protocol. Because conditions 2–4 are not met in this codebase, the vulnerability is not currently exploitable here. This upgrade is still the correct defense-in-depth move.

---

ℹ️ Note: v5.9.0 Performance Improvements Partially Inapplicable

v5.9.0 significantly reduces network round-trips by skipping Describe Portal for cached prepared statements. However, with PreferSimpleProtocol: true, the prepared statement pathway is bypassed entirely, so those gains don't apply to this service. This is a pre-existing design tradeoff, not a regression.

---

⚠️ Medium Risk (Pre-existing, Not Introduced by This PR): Raw SQL String Interpolation

While reviewing how pgx is exercised, I identified pre-existing injection surfaces that are independent of this bump but worth tracking:

storage/sql.go — UpdateMigrationTable:

statement = fmt.Sprintf(`INSERT INTO %s.migrations VALUES(%v, '%v', '%v', %v)`, s.GetSchemaName(), id, name, desc, time.Now().UnixMilli())

name and desc are interpolated directly into the SQL string without parameterization. If either value is ever sourced from untrusted input (e.g., a user-supplied migration descriptor), this is a SQL injection vector.

leadership/leadership.go:292:

statement = fmt.Sprintf(`SELECT * FROM %s.%s WHERE id='%s'`, l.storage.GetSchemaName(), l.tableName, l.Leader.Id)

l.Leader.Id is string-interpolated directly.

These should be replaced with parameterized queries, e.g.:

// Instead of fmt.Sprintf with '%v'/'%s' for values, use GORM's Exec with args:
s.DB.Exec("INSERT INTO "+schema+".migrations VALUES(?, ?, ?, ?)", id, name, desc, time.Now().UnixMilli())

---

✅ Verdict: Safe to Merge

This is a security patch release that is a net positive. The Go version constraint is already met, there are no breaking pgx API changes between 5.6 and 5.9 that affect GORM's usage surface, and the CVE fix applies as defense-in-depth even though the specific attack pattern isn't present in the codebase today.

Would you like me to open a follow-up issue to track the pre-existing raw SQL interpolation concerns in UpdateMigrationTable and leadership.go?

[Lutherwaves]

[!TIP]
For best results, initiate chat on the files or code changes.

🧩 Analysis chain

Let me inspect the codebase to assess the risks properly.

---

🏁 Script executed:

#!/bin/bash
# Check Go version requirement in go.mod
cat go.mod

echo "---"
# Check how pgx is used in the codebase
rg -n --type=go 'pgx|pgxpool|QueryExecMode|SimpleProtocol|Batch|SendBatch' -C2

Length of output: 5381

---

Let me dig deeper into the SQL usage patterns.

---

🏁 Script executed:

#!/bin/bash
# Read full sql.go
cat storage/sql.go

echo "==="
# Look for any raw SQL queries with dollar signs (potential injection surface)
rg -n --type=go '\$[0-9]|\$[a-zA-Z]|dollar|Exec\(|Raw\(' -C3

echo "==="
# Check gorm postgres driver version (the bridge between gorm and pgx)
grep -i 'gorm.io/driver/postgres' go.mod go.sum | head -10

Length of output: 26114

---

@Lutherwaves: Here's a thorough risk assessment of this bump from pgx v5.6.0 → v5.9.2.

---

Risk Assessment: github.com/jackc/pgx/v5 5.6.0 → 5.9.2

✅ No Risk: Go 1.25 Requirement (v5.9.0)

Your go.mod already declares go 1.25.0, so the new minimum Go version constraint introduced in v5.9.0 is already satisfied. No action needed.

---

✅ No Risk: Batch Result Corruption (v5.9.1)

The codebase has no direct use of pgx batch operations (SendBatch, etc.). pgx is consumed through GORM as an abstraction layer, and GORM does not use pgx batching. The v5.9.1 fix is not applicable here.

---

⚠️ Low Risk (Mitigated by Upgrade): SQL Injection via Dollar-Quoted Strings — GHSA-j88v-2chj-qfwx (v5.9.2)

This vulnerability requires all four conditions simultaneously:

1. Simple protocol in use — MET: storage/sql.go:72 sets PreferSimpleProtocol: true
2. A dollar-quoted string literal in the SQL (e.g., $tag$...$tag$) — NOT found in the codebase
3. A placeholder appearing inside the literal — NOT found
4. Attacker-controlled placeholder value — NOT applicable

The GORM docs document PreferSimpleProtocol: true as the flag that "disables implicit prepared statement usage" — by default pgx uses the extended protocol. Because conditions 2–4 are not met in this codebase, the vulnerability is not currently exploitable here. This upgrade is still the correct defense-in-depth move.

---

ℹ️ Note: v5.9.0 Performance Improvements Partially Inapplicable

v5.9.0 significantly reduces network round-trips by skipping Describe Portal for cached prepared statements. However, with PreferSimpleProtocol: true, the prepared statement pathway is bypassed entirely, so those gains don't apply to this service. This is a pre-existing design tradeoff, not a regression.

---

⚠️ Medium Risk (Pre-existing, Not Introduced by This PR): Raw SQL String Interpolation

While reviewing how pgx is exercised, I identified pre-existing injection surfaces that are independent of this bump but worth tracking:

storage/sql.go — UpdateMigrationTable:

statement = fmt.Sprintf(`INSERT INTO %s.migrations VALUES(%v, '%v', '%v', %v)`, s.GetSchemaName(), id, name, desc, time.Now().UnixMilli())

name and desc are interpolated directly into the SQL string without parameterization. If either value is ever sourced from untrusted input (e.g., a user-supplied migration descriptor), this is a SQL injection vector.

leadership/leadership.go:292:

statement = fmt.Sprintf(`SELECT * FROM %s.%s WHERE id='%s'`, l.storage.GetSchemaName(), l.tableName, l.Leader.Id)

l.Leader.Id is string-interpolated directly.

These should be replaced with parameterized queries, e.g.:

// Instead of fmt.Sprintf with '%v'/'%s' for values, use GORM's Exec with args:
s.DB.Exec("INSERT INTO "+schema+".migrations VALUES(?, ?, ?, ?)", id, name, desc, time.Now().UnixMilli())

---

✅ Verdict: Safe to Merge

This is a security patch release that is a net positive. The Go version constraint is already met, there are no breaking pgx API changes between 5.6 and 5.9 that affect GORM's usage surface, and the CVE fix applies as defense-in-depth even though the specific attack pattern isn't present in the codebase today.

Would you like me to open a follow-up issue to track the pre-existing raw SQL interpolation concerns in UpdateMigrationTable and leadership.go?

Yes open a follow up issue