CVE-2025-1094

What it actually does

The flaw is an SQL injection condition in PostgreSQL client-side escaping and command-line handling. In affected PostgreSQL versions, libpq escaping functions including PQescapeLiteral(), PQescapeIdentifier(), PQescapeString(), and PQescapeStringConn() can fail to neutralize quoting syntax correctly in specific character-encoding combinations and usage patterns. Exploitation is constrained: the escaped result must be used to construct input that is later processed by psql, or a vulnerable PostgreSQL command-line utility must receive attacker-influenced command-line arguments while client_encoding is BIG5 and server_encoding is EUC_TW or MULE_INTERNAL. When those conditions are met, attacker-controlled input can break out of the intended quoted context and inject arbitrary SQL, potentially enabling unauthorized reads, writes, privilege abuse, destructive database operations, or execution of database-side functionality available to the connected role.

Why it matters to the business

Successful exploitation can let an attacker manipulate database queries that the application or administrative tooling intended to run safely. Depending on the privileges of the database connection, this can result in exposure of sensitive data, unauthorized data changes, account or application takeover paths, data destruction, service disruption, and loss of integrity in systems that rely on PostgreSQL-backed workflows. Although the attack requires specific encoding and tool-usage conditions, the risk is elevated because exploit maturity is listed as weaponized, the EPSS score is very high, and the issue has been public for a long period, increasing the likelihood that scanners, proof-of-concept logic, and opportunistic exploitation techniques are available. For the listed downstream product, podlove/podlove-publisher from Git should be updated to a revision containing commit f40749a6bdd87e07cee866b8d37bb1748ab60c35 or later.

How an attack unfolds

An attacker first looks for an application, job, plugin, migration script, import process, or administrative workflow that accepts attacker-controlled database values or command-line arguments and later uses PostgreSQL escaping output to build SQL sent through psql or another affected PostgreSQL command-line utility. The attacker then determines whether the vulnerable encoding preconditions are present, particularly BIG5 as the client encoding with EUC_TW or MULE_INTERNAL as the server encoding. They supply specially crafted multibyte input containing quoting syntax that is mishandled by the affected escaping path. When the application or utility constructs a SQL command from that input, the malformed escaping allows the payload to terminate the intended string or identifier context and append attacker-chosen SQL. The injected SQL then runs with the permissions of the database role used by the vulnerable process, which may allow data theft, modification, object creation, privilege escalation inside the database, or destructive commands. In downstream applications such as podlove/podlove-publisher, the practical exposure depends on whether affected PostgreSQL client behavior is reachable through application-controlled input and whether the fixed commit has been applied.

How to fix it

Upgrade affected PostgreSQL installations and client libraries to fixed versions: PostgreSQL 17.3 or later, 16.7 or later, 15.11 or later, 14.16 or later, and 13.19 or later. Ensure both server packages and client-side packages such as libpq, psql, and PostgreSQL command-line utilities are updated, because vulnerable behavior may exist on the client side even when the database server is patched. For podlove/podlove-publisher installed from Git, update to a revision that includes commit f40749a6bdd87e07cee866b8d37bb1748ab60c35 or later. Rebuild containers, application images, and statically packaged dependencies that include PostgreSQL client libraries. As defense in depth, avoid constructing SQL by concatenating escaped strings for psql input; use parameterized queries, structured database APIs, safe dump/restore mechanisms, and strict separation between data and SQL syntax. Where possible, avoid the vulnerable encoding combinations, especially BIG5 client encoding paired with EUC_TW or MULE_INTERNAL server encoding. Restrict database roles used by automation and applications to the least privileges required, and prevent untrusted users from controlling command-line arguments or SQL fragments passed to PostgreSQL utilities.

How to confirm the fix worked

Confirm installed PostgreSQL server and client package versions are at or above the fixed release lines: 17.3, 16.7, 15.11, 14.16, or 13.19. Validate libpq and psql versions separately on application hosts, build agents, containers, administrative workstations, and job runners, because vulnerable client tooling may remain after the server is upgraded. For podlove/podlove-publisher Git deployments, verify the deployed revision contains commit f40749a6bdd87e07cee866b8d37bb1748ab60c35 or a later upstream fix. Review build manifests, container SBOMs, package lock files, and OS package inventories for older PostgreSQL client packages. Check database configuration for risky encoding combinations by reviewing client_encoding and server_encoding settings, and confirm that applications do not force BIG5 client encoding when the server uses EUC_TW or MULE_INTERNAL. Perform code review for uses of PQescapeLiteral(), PQescapeIdentifier(), PQescapeString(), and PQescapeStringConn() where the result is used to construct input for psql rather than executed through parameterized APIs. Finally, run representative application workflows after patching to ensure database import/export, maintenance, and plugin features continue to operate correctly.

Typical attack path

1. Identify a PostgreSQL-backed application, plugin, script, or operational workflow using affected PostgreSQL client utilities or libpq escaping functions.
2. Find an input path where attacker-controlled data is later incorporated into SQL executed through psql or a vulnerable PostgreSQL command-line utility.
3. Confirm or infer that the relevant database/client encoding combination is in use, especially client_encoding BIG5 with server_encoding EUC_TW or MULE_INTERNAL.
4. Submit crafted multibyte input designed to defeat quoting or escaping in the vulnerable function or utility path.
5. Trigger the application, import job, maintenance process, or command-line workflow to generate and execute SQL using the attacker-controlled value.
6. Have the injected SQL execute under the privileges of the database role used by the vulnerable process.
7. Use database access to read sensitive records, alter application data, create persistence inside the database, disrupt service, or pivot to additional application compromise paths.

How to detect it

There is no single reliable network or host indicator that proves exploitation, so detection should focus on suspicious behavior around PostgreSQL command construction, psql execution, risky encodings, and anomalous SQL activity. Review PostgreSQL server logs for sessions using BIG5 client encoding with EUC_TW or MULE_INTERNAL server encoding, unexpected SET client_encoding statements, repeated SQL syntax errors, invalid multibyte sequence errors, and queries containing stacked statements or comment delimiters in places normally populated by user data. Review application logs, worker logs, import/export logs, plugin logs, and maintenance job logs for failed or unusual database operations shortly before data changes or privilege changes. On hosts running applications or automation, review process execution telemetry, shell history, cron/systemd timers, CI logs, and EDR data for psql invocations that include attacker-influenced files, inline commands, unusual encodings, or unexpected SQL script paths. If database auditing is enabled, inspect for unauthorized SELECT, COPY, CREATE FUNCTION, CREATE EXTENSION, ALTER ROLE, GRANT, DROP, TRUNCATE, or mass UPDATE/DELETE statements executed by application or automation roles. Compare database object creation/modification times, role grants, scheduled jobs, extensions, and large data exports against expected deployment activity. For web-facing applications, correlate suspicious request parameters containing quotes, SQL metacharacters, multibyte characters, or encoding-related payloads with downstream PostgreSQL errors or administrative psql executions. Because this issue is client-side and usage-pattern dependent, absence of a known IOC does not rule out exploitation; behavioral review and patch validation are required.

• PQescapeLiteral(
• PQescapeIdentifier(
• PQescapeString(
• PQescapeStringConn(
• SET client_encoding = 'BIG5'
• SET client_encoding TO 'BIG5'
• client_encoding=BIG5
• server_encoding = 'EUC_TW'
• server_encoding = 'MULE_INTERNAL'
• ERROR: invalid byte sequence for encoding
• ERROR: unterminated quoted string
• ERROR: syntax error at or near
• psql: error:
• psql -c
• psql -f
• COPY
• CREATE EXTENSION
• CREATE FUNCTION
• ALTER ROLE
• GRANT ALL
• DROP TABLE
• TRUNCATE TABLE
• --
• /*

What your security team should do

• Prioritize patching because exploit maturity is weaponized and the EPSS score is high, even though the flaw has specific exploitation preconditions.
• Inventory PostgreSQL client libraries and utilities across servers, containers, CI/CD runners, developer images, administrative jump hosts, and application dependencies; do not limit review to database servers.
• Upgrade PostgreSQL to fixed versions 17.3, 16.7, 15.11, 14.16, or 13.19 and ensure libpq and psql are updated everywhere they are used.
• For podlove/podlove-publisher Git deployments, update to commit f40749a6bdd87e07cee866b8d37bb1748ab60c35 or later.
• Search code and scripts for PQescapeLiteral(), PQescapeIdentifier(), PQescapeString(), and PQescapeStringConn(), prioritizing cases where escaped output is written into psql scripts, shell commands, migration files, or administrative SQL batches.
• Identify and reduce use of BIG5 client encoding with EUC_TW or MULE_INTERNAL server encoding; treat those systems as higher priority for remediation.
• Harden database permissions for application and automation roles so a successful SQL injection has limited blast radius.
• Review PostgreSQL logs, application logs, job-runner logs, shell history, and audit logs for suspicious psql activity, encoding changes, SQL syntax errors, and unexpected database modifications during the exposure window.
• Add regression tests or static-analysis checks to prevent new code from building SQL for psql from attacker-controlled input.