Critical PostgreSQL Flaws Allow Code Injection During Database Restoration

The PostgreSQL Global Development Group has disclosed critical vulnerabilities that could allow attackers to inject and execute arbitrary code during routine database restoration procedures. These flaws—CVE-2025-8714, CVE-2025-8715, and CVE-2025-1094—pose serious risks to database integrity and system security, particularly for environments relying on PostgreSQL’s `pg_dump`, `pg_restore`, and related utilities.

Malicious Code Injection Enabled by PostgreSQL Backup Utilities

All three vulnerabilities exploit PostgreSQL’s backup and restore mechanisms to enable code execution on client or server systems.

CVE-2025-8714 Lets Origin Server Superusers Inject Arbitrary Commands

CVE-2025-8714 is a critical flaw affecting PostgreSQL versions before 17.6, 16.10, 15.14, 14.19, and 13.22. The issue stems from the PostgreSQL `pg_dump` utility, which can be manipulated by a superuser account on the source (origin) server to insert malicious code into database backup files. If these compromised files are later restored using `psql`, the code is executed with the operating system privileges of the local client initiating the restore. This vulnerability impacts:

• `pg_dump`: during plain-text output
• `pg_dumpall`: for consolidated dumps
• `pg_restore`: under certain formats when used improperly

In effect, a privileged actor on the source system can weaponize backup files. Any downstream user or system that restores those backups via `psql` immediately becomes subject to arbitrary code execution.

CVE-2025-8715 Exploits Newline Characters in Object Names

CVE-2025-8715 introduces another critical code injection vector, also affecting `pg_dump` and its related utilities. This vulnerability results from improperly sanitized newline characters in object names. By crafting a malicious object name that contains newline characters followed by `psql` meta-commands, an attacker can embed executable code into the dump output. Upon restoration, the following scenarios are possible:

• The malicious code is executed on the client system through `psql`
• If used with `pg_upgrade`, the payload can execute on the target server
• SQL injection during restore proceeds with superuser privileges

Affected versions are the same as with CVE-2025-8714—PostgreSQL 13 through 17 prior to their respective security-patched versions. Analysts stress that because object names are commonly overlooked for input sanitization, this flaw may be easier to exploit in automated or CI/CD restore processes, especially in environments without tightly controlled administrative procedures.

Underlying SQL Injection Risk in PostgreSQL Quoting APIs

CVE-2025-1094 Highlights Longstanding Weakness in Encoding Validation

The third vulnerability, CVE-2025-1094, is a high-severity SQL injection issue unrelated to `pg_dump` but equally worth noting for PostgreSQL administrators. It affects `libpq`, the PostgreSQL client library, specifically its quoting APIs:

• `PQescapeLiteral()`
• `PQescapeIdentifier()`
• `PQescapeString()`
• `PQescapeStringConn()`

Due to improper neutralization of quoting syntax in text that fails encoding validation, attackers can exploit these functions when they are used in certain application patterns. Exploits could allow attackers to inject arbitrary SQL commands, especially in scenarios where user input is passed into these APIs and assumed to be safe. Versions before PostgreSQL 17.3, 16.7, 15.11, 14.16, and 13.19 are vulnerable to this issue.

Broad Impact Across Backup, Restore, and Upgrade Workflows

Across these vulnerabilities, the common theme is the potential for attackers to subvert trust during database backup and restore operations. Because operations like `pg_dump`, `pg_dumpall`, `pg_restore`, and `pg_upgrade` are core to PostgreSQL database administration, they are often either:

• Automated via scripts (e.g., in CI/CD deploy pipelines), or
• Assumed to be safe in staging and production environments

This makes exploitation particularly dangerous, especially in organizations where backups and restores happen regularly, or where multiple administrators and systems handle PostgreSQL dumps.

Urgent Mitigation Requires Immediate Patching and Privilege Audits

Upgrade to Patched Releases

The PostgreSQL Global Development Group has issued patched versions addressing all three vulnerabilities:

Vulnerability	Patched in Version

Administrators should immediately confirm their running versions and apply these updates. Delays could expose restore processes to adversarial code execution or SQL injection attacks.

Limit Superuser and Administrative Access

Because CVE-2025-8714 and CVE-2025-8715 both rely on malicious behavior by users with elevated database privileges, security teams should:

• Conduct privilege audits on PostgreSQL role assignments
• Minimize use of `pg_dumpall` and plain-text formats when possible
• Use structured, custom-format dumps with signed control files for better validation

Sanitize and Inspect Backup Files

Until systems are upgraded, organizations should treat PostgreSQL backups as untrusted input:

• Avoid restoring old backup files without reviewing them manually
• Parse `.sql` dump files for anomalous object names or embedded `psql` commands
• Isolate the restoration process to sandboxed environments if review is not feasible

PostgreSQL Backup Tools Must Be Treated as Attack Surfaces

These recent disclosures highlight how essential PostgreSQL utilities—long perceived as benign infrastructure components—can become attack vectors when privilege assumptions and input validation fail. With the severity of CVE-2025-8714 and CVE-2025-8715, PostgreSQL administrators and CISOs must reassess their backup and restoration workflows, moving beyond functional reliability to active threat modelling. Given the widespread use of PostgreSQL across enterprise and cloud-native workloads, prompt patching and restricted privilege design are the most effective defenses against these critical security flaws.