The Security Scanning CI gate has been failing on main since at least 2026-06-26 with:
```
Vulnerability #1: GO-2026-5004
SQL Injection via placeholder confusion with dollar quoted string literals
in github.com/jackc/pgx
Module: github.com/jackc/pgx/v5
Found in: github.com/jackc/pgx/v5@v5.8.0
Fixed in: github.com/jackc/pgx/v5@v5.9.2
Example traces found:
#1: internal/database/connection.go:353:25: database.Connection.ReleaseAdvisoryLock
calls pgxpool.Conn.QueryRow, which eventually calls sanitize.SanitizeSQL
```
govulncheck classifies this as a real call-graph hit (not just an import) because
`database.Connection.ReleaseAdvisoryLock` reaches `sanitize.SanitizeSQL` through
`pgxpool.Conn.QueryRow`. We don't pass attacker-controlled SQL into that path
(the only argument is a deterministic int64 lock key), so this is unlikely
exploitable in CUDly today, but it keeps the Security Scanning gate red on every
PR -- which is itself a problem (real future findings drown in the noise).
Fix
Bump `github.com/jackc/pgx/v5` from v5.8.0 to v5.9.2 in the root `go.mod` and
re-run `go mod tidy`. Verify with:
```bash
go install golang.org/x/vuln/cmd/govulncheck@v1.1.4
for mod in . pkg providers/aws providers/azure providers/gcp tests/e2e; do
echo "==> govulncheck in $mod"
(cd "$mod" && govulncheck ./...)
done
```
Out of scope here
The Security Scanning CI gate also runs across the per-cloud submodules; check
each one for the same advisory after the root bump and lift versions in sync if
needed (PR #1277 surfaced this; the lint-flood issue is tracked separately in
#1223).
The Security Scanning CI gate has been failing on main since at least 2026-06-26 with:
```
Vulnerability #1: GO-2026-5004
SQL Injection via placeholder confusion with dollar quoted string literals
in github.com/jackc/pgx
Module: github.com/jackc/pgx/v5
Found in: github.com/jackc/pgx/v5@v5.8.0
Fixed in: github.com/jackc/pgx/v5@v5.9.2
Example traces found:
#1: internal/database/connection.go:353:25: database.Connection.ReleaseAdvisoryLock
calls pgxpool.Conn.QueryRow, which eventually calls sanitize.SanitizeSQL
```
govulncheck classifies this as a real call-graph hit (not just an import) because
`database.Connection.ReleaseAdvisoryLock` reaches `sanitize.SanitizeSQL` through
`pgxpool.Conn.QueryRow`. We don't pass attacker-controlled SQL into that path
(the only argument is a deterministic int64 lock key), so this is unlikely
exploitable in CUDly today, but it keeps the Security Scanning gate red on every
PR -- which is itself a problem (real future findings drown in the noise).
Fix
Bump `github.com/jackc/pgx/v5` from v5.8.0 to v5.9.2 in the root `go.mod` and
re-run `go mod tidy`. Verify with:
```bash
go install golang.org/x/vuln/cmd/govulncheck@v1.1.4
for mod in . pkg providers/aws providers/azure providers/gcp tests/e2e; do
echo "==> govulncheck in $mod"
(cd "$mod" && govulncheck ./...)
done
```
Out of scope here
The Security Scanning CI gate also runs across the per-cloud submodules; check
each one for the same advisory after the root bump and lift versions in sync if
needed (PR #1277 surfaced this; the lint-flood issue is tracked separately in
#1223).