CVE-2025-1094 Overview
CVE-2025-1094 is a SQL injection vulnerability in PostgreSQL's libpq client library. The flaw resides in the quoting functions PQescapeLiteral(), PQescapeIdentifier(), PQescapeString(), and PQescapeStringConn(), which fail to properly neutralize quoting syntax under specific encoding conditions. Attackers can exploit this issue when application code passes escaped output to psql, the PostgreSQL interactive terminal. A parallel issue exists in PostgreSQL command line utilities when client_encoding is BIG5 and server_encoding is either EUC_TW or MULE_INTERNAL. The vulnerability is classified under [CWE-149] (Improper Neutralization of Quoting Syntax).
Critical Impact
A database input provider can inject arbitrary SQL commands, leading to data confidentiality, integrity, and availability compromise across affected PostgreSQL deployments.
Affected Products
- PostgreSQL versions before 17.3
- PostgreSQL versions before 16.7, 15.11, and 14.16
- PostgreSQL versions before 13.19
Discovery Timeline
- 2025-02-13 - CVE-2025-1094 published to NVD
- 2025-02-15 - Debian LTS announcement released
- 2025-02-16 - OpenWall OSS Security discussion published
- 2025-02-20 - OpenWall OSS Security update released
- 2025-02-21 - NetApp Security Advisory ntap-20250221-0010 published
- 2025-02-24 - Second Debian LTS announcement issued
- 2026-04-15 - Last updated in NVD database
Technical Details for CVE-2025-1094
Vulnerability Analysis
The vulnerability stems from improper handling of multi-byte character encoding boundaries in PostgreSQL's escape functions. When libpq processes input intended for SQL string literals or identifiers, the escape routines do not correctly account for invalid byte sequences in certain client encodings. An attacker who controls input passed to these functions can craft byte sequences that bypass the quoting logic.
Exploitation requires a specific downstream usage pattern: the escaped output must be forwarded to psql, where it is interpreted as commands. Because psql processes meta-commands and SQL statements, an injected payload can execute arbitrary SQL or invoke shell commands through psql features such as \!. The CWE-149 classification reflects the root cause in quoting syntax neutralization.
Root Cause
The escape functions assume that supplied input conforms to the declared client encoding. When the input contains malformed multi-byte sequences, the parser misidentifies byte boundaries and leaves quote characters un-escaped. The companion issue in command line utilities arises specifically when client_encoding is set to BIG5 while server_encoding is EUC_TW or MULE_INTERNAL, producing similar boundary confusion during argument processing.
Attack Vector
An attacker supplies crafted input to an application that calls one of the affected libpq escape functions. The application then passes the resulting string to psql for execution. Because the escape routine failed to neutralize the injected quote, psql interprets attacker-controlled bytes as SQL syntax or meta-commands. The attack is network-reachable wherever the application accepts remote input destined for a PostgreSQL toolchain workflow.
No verified public proof-of-concept code is referenced in the advisory. Refer to the PostgreSQL Security Advisory CVE-2025-1094 for authoritative technical detail.
Detection Methods for CVE-2025-1094
Indicators of Compromise
- Unexpected psql meta-command execution, particularly \! shell escapes originating from application-driven sessions
- Anomalous SQL statements in PostgreSQL audit logs that include unescaped single quotes adjacent to high-bit byte sequences
- Database sessions originating from application service accounts that execute DDL or privilege-changing statements outside normal workflows
- Use of BIG5 client encoding combined with EUC_TW or MULE_INTERNAL server encoding in connection logs
Detection Strategies
- Enable log_statement = 'all' on affected PostgreSQL servers and review logs for malformed multi-byte sequences in query strings
- Inspect application source for direct invocation of psql with arguments built from PQescapeLiteral(), PQescapeIdentifier(), PQescapeString(), or PQescapeStringConn() output
- Correlate process execution telemetry on database hosts to flag psql child processes spawning shells or external binaries
Monitoring Recommendations
- Forward PostgreSQL logs and host process telemetry into a centralized analytics platform for cross-source correlation
- Alert on psql invocations that include \!, \copy, or \i meta-commands when launched by application service accounts
- Track installed PostgreSQL package versions across the fleet and alert on hosts running releases prior to 17.3, 16.7, 15.11, 14.16, or 13.19
How to Mitigate CVE-2025-1094
Immediate Actions Required
- Upgrade PostgreSQL server and client packages to 17.3, 16.7, 15.11, 14.16, 13.19, or later on every affected host
- Audit application code that pipes escaped strings into psql and refactor to use parameterized queries through libpq directly
- Restrict and rotate credentials for any PostgreSQL roles accessible to applications that handle untrusted input
Patch Information
The PostgreSQL Global Development Group released fixed builds on the February 2025 update cycle. Distribution-specific patches are available through the Debian LTS Announcement 2025-02-15, the Debian LTS Announcement 2025-02-24, and the NetApp Security Advisory ntap-20250221-0010. Apply the vendor-supplied package for your platform and restart the PostgreSQL service.
Workarounds
- Avoid passing the output of libpq escape functions to psql as command-line arguments or standard input until patching is complete
- Set client_encoding to a value other than BIG5 when communicating with servers using EUC_TW or MULE_INTERNAL
- Restrict network access to PostgreSQL servers using firewall rules so only trusted application hosts can connect
# Verify installed PostgreSQL version against fixed releases
psql --version
# Example Debian/Ubuntu upgrade path
sudo apt-get update
sudo apt-get install --only-upgrade postgresql postgresql-client libpq5
sudo systemctl restart postgresql
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


