CVE-2026-41889

What it actually does

This is a SQL injection vulnerability in the Go PostgreSQL driver/toolkit pgx before version 5.9.2. The flaw is reachable only under a specific combination of conditions: the application uses pgx's non-default simple protocol, the SQL statement contains a PostgreSQL dollar-quoted string literal, that literal includes text resembling a positional placeholder such as $1 or $2, and an attacker controls the value associated with the affected placeholder. Under those conditions, pgx can incorrectly interpret placeholder-like text inside the dollar-quoted literal and mishandle parameter substitution, allowing attacker-controlled input to alter the intended SQL statement. The likely impact is unauthorized modification or manipulation of database queries, with potential data tampering depending on the application's query privileges and how the vulnerable query is constructed.

Why it matters to the business

Applications using affected pgx versions may allow users to tamper with backend database operations if the application uses the vulnerable query pattern. Business consequences can include incorrect records, unauthorized updates, bypassed application logic, fraudulent transactions, or integrity loss in PostgreSQL-backed systems. The issue has a high CVSS score, but exploitation appears narrowly scoped because it requires the non-default simple protocol and a specific SQL construction pattern. EPSS is low and flat over the last 30 days, it is not listed in CISA KEV, and no public exploit maturity is reported, so remediation should be prioritized for exposed or business-critical applications but treated as a targeted-risk vulnerability rather than a broadly exploited internet-wide issue.

How an attack unfolds

An attacker first identifies an application endpoint or workflow backed by Go code using pgx to query PostgreSQL. The vulnerable application must be using pgx's simple protocol rather than the default extended protocol. The attacker then targets functionality where their input is passed as a query parameter to SQL containing a PostgreSQL dollar-quoted string literal. If that dollar-quoted literal contains placeholder-looking text such as $1 that pgx incorrectly treats as a real placeholder, parameter handling can become misaligned or improperly interpolated. The attacker submits crafted input that escapes the intended data context or changes the resulting SQL semantics. Successful exploitation can let the attacker modify filters, append SQL fragments, alter update conditions, or otherwise manipulate database operations within the privileges of the application's database account.

How to fix it

Upgrade github.com/jackc/pgx to version 5.9.2 or later. In Go modules, update the dependency with a command such as `go get github.com/jackc/pgx/v5@v5.9.2` followed by `go mod tidy`, then rebuild and redeploy affected services. If immediate upgrade is not possible, avoid pgx simple protocol for queries involving user-controlled parameters, especially queries containing PostgreSQL dollar-quoted strings. Prefer the default extended protocol and server-side parameter binding. Review SQL statements that combine dollar-quoted literals and placeholders, and refactor them to avoid placeholder-like tokens inside dollar-quoted strings where possible. Maintain least-privilege PostgreSQL roles so that any injection impact is limited to the minimum required database permissions.

How to confirm the fix worked

Confirm dependency versions by inspecting `go.mod`, `go.sum`, SBOMs, and built artifact metadata for `github.com/jackc/pgx/v5` versions earlier than 5.9.2. Use `go list -m all | grep 'github.com/jackc/pgx'` in source repositories or build pipelines to verify the resolved version. Search application code for simple-protocol usage such as `QueryExecModeSimpleProtocol`, `DefaultQueryExecMode`, `PreferSimpleProtocol`, or `pgx.QueryExecModeSimpleProtocol`. Review SQL strings in those code paths for PostgreSQL dollar-quoted literals such as `$$...$$` or `$tag$...$tag$` that contain placeholder-like tokens such as `$1`, `$2`, or `$3`. After upgrading, rerun integration tests for affected database paths and, where feasible, add regression tests using dollar-quoted SQL containing placeholder-like text plus attacker-controlled parameter values to confirm the generated query behavior is safe.

Typical attack path

1. Find an application feature that accepts user-controlled input and stores, searches, filters, or updates PostgreSQL data.
2. Determine or infer that the application is written in Go and uses the jackc/pgx PostgreSQL driver before 5.9.2.
3. Reach a code path configured to use pgx simple protocol, such as QueryExecModeSimpleProtocol or equivalent simple-protocol settings.
4. Trigger a SQL statement that contains a PostgreSQL dollar-quoted string literal with placeholder-like text inside it, such as $1 or $2.
5. Submit crafted parameter values designed to change the final SQL statement after pgx performs placeholder handling.
6. Observe behavioral differences, database errors, timing changes, unauthorized records, or modified results to confirm injection.
7. Use the injection point to alter query logic or data within the permissions granted to the application's PostgreSQL role.

How to detect it

To assess possible prior exploitation, review application access logs, application error logs, PostgreSQL statement logs, audit logs, and database activity monitoring records for endpoints that accept user input and execute PostgreSQL queries through pgx. Focus on services using pgx before 5.9.2 with simple protocol enabled. Look for SQL syntax errors, unusual changes in query shape, unexpected boolean logic, comment markers, stacked statements, time-delay probes, or access to catalog tables near suspicious requests. PostgreSQL logs may show failed or unusual statements if `log_statement`, `log_min_error_statement`, `pgaudit`, or equivalent database monitoring was enabled. Application logs may show database errors such as syntax errors near injected tokens, unterminated quoted strings, malformed dollar-quoted strings, or parameter-count mismatches. Because exploitation depends heavily on application-specific SQL construction, absence of generic indicators does not prove absence of exploitation; correlate suspicious database statements with HTTP parameters, authenticated user actions, and unexpected data modifications.

• QueryExecModeSimpleProtocol
• PreferSimpleProtocol
• DefaultQueryExecMode
• pgx.QueryExecModeSimpleProtocol
• github.com/jackc/pgx/v5 v5.9.1
• github.com/jackc/pgx/v5 v5.9.0
• github.com/jackc/pgx/v5 v5.8.
• github.com/jackc/pgx/v5 v5.7.
• unterminated dollar-quoted string
• syntax error at or near "UNION"
• syntax error at or near "--"
• syntax error at or near "/*"
• UNION SELECT
• OR 1=1
• AND 1=1
• pg_sleep(
• information_schema
• pg_catalog
• COPY
• TO PROGRAM
• DROP TABLE
• ALTER TABLE

What your security team should do

• Inventory all Go applications and services that use `github.com/jackc/pgx` or `github.com/jackc/pgx/v5`.
• Prioritize internet-facing, multi-tenant, payment, identity, administrative, and data-modifying applications using pgx versions earlier than 5.9.2.
• Upgrade pgx to 5.9.2 or later and redeploy affected binaries; remember that Go applications must be rebuilt for dependency updates to take effect.
• Search code for pgx simple-protocol configuration and treat those locations as highest risk.
• Review PostgreSQL logs and application logs for SQL errors or suspicious query patterns around user-controlled workflows before and after remediation.
• Temporarily disable or refactor vulnerable simple-protocol query paths if an immediate dependency upgrade cannot be deployed.
• Ensure application database roles do not have unnecessary write, schema modification, superuser, file access, or extension creation privileges.
• Add SCA policy checks to block future builds using pgx versions earlier than 5.9.2.