A new critical vulnerability in pgAdmin 4 allows remote attackers to bypass security filters and execute arbitrary shell commands on the host server.
The flaw, tracked as CVE-2025-13780, exploits a weakness in how the popular PostgreSQL management tool processes database restoration files.
| CVE ID | CVE-2025-13780 |
|---|---|
| Severity | Critical |
| Vulnerability Type | Remote Code Execution (RCE) |
| Affected Component | pgAdmin 4 (Restore Feature) |
Security researchers discovered that the application’s “regex firewall” failed to account for specific whitespace characters, leaving a direct path for Remote Code Execution (RCE).
The core issue resides in the plain-text restore feature of pgAdmin 4. When a user restores a database from a SQL file, the application launches the psql command-line utility to process the data.
Since psql supports powerful meta-commands that can run operating system commands, pgAdmin attempts to block these dangerous commands using a regular expression (regex) check.
This check was designed to reject files containing meta-commands like !, which execute shell scripts.
The security failure occurred because the regex filter was too rigid. It only looked for backslashes at the very beginning of a line or immediately following a standard newline character.
Researchers found that inserting alternative whitespace characters, such as a carriage return (\r), between the newline and the command could hide the malicious code from the filter.
While the Python-based regex recognized safe text, the underlying psql interpreter treated the sequence as a valid newline and executed the command.
According to Endor Labs, this discrepancy allowed attackers to craft SQL files that appeared harmless to pgAdmin but triggered code execution when processed.
In a proof-of-concept demonstration, researchers successfully created a file named crlf_attack.sql that executed shell commands on the pgAdmin host server immediately upon restoration.
The development team addressed this in pgAdmin 4 version 9.11 by changing their approach entirely.
Instead of filtering the input file with complex text matching, the application now launches the restore process with the restrict option.
This directive forces the psql interpreter itself to turn off potentially dangerous meta-commands during execution.
This method provides a much more vigorous defense because it relies on the database tool’s own internal security controls rather than an external text scanner.
Administrators are urged to upgrade to version 9.11 immediately to mitigate this risk, as regex-based patches for complex parsers frequently leave residual gaps for attackers to exploit.
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.