A critical security vulnerability in pgAdmin four has been discovered that allows attackers to execute arbitrary shell commands on the host system by bypassing the application’s regex-based security filter.
Tracked as CVE-2025-13780, the flaw affects pgAdmin across four versions before 9.11 and exploits weaknesses in how the database administration tool validates plain-text restore operations.
| CVE ID | Description | Severity | CVSS Score | Affected Versions | Fixed Version | Attack Vector | Impact | Exploit Available |
|---|---|---|---|---|---|---|---|---|
| CVE-2025-13780 | Remote code execution via meta-command injection in pgAdmin 4 plain-text restore feature | Critical | N/A | pgAdmin 4 versions prior to 9.11 | pgAdmin 4 v9.11 | Network | Remote Code Execution (RCE) on pgAdmin host | Yes (PoC available) |
How the Vulnerability Works
The vulnerability stems from pgAdmin 4’s plain-text restore feature, which uses the psql client to process uploaded database dumps.
When restoring a PLAIN-format dump, pgAdmin launches psql on the host system and passes the uploaded SQL file to it.
However, psql supports powerful meta-commands prefixed with backslashes that can execute shell commands, copy files, and spawn processes.
To prevent abuse, pgAdmin implemented a regex-based filter designed to detect and block dangerous psql meta-commands in uploaded files.
The security check used a regular expression pattern that searched for backslashes at the start of lines, allowing only spaces and tabs as leading whitespace.
However, researchers discovered that this filter could be easily bypassed by using whitespace characters that psql recognizes, but the regex does not.
Attackers can exploit CVE-2025-13780 by crafting malicious SQL dump files containing meta-commands hidden behind alternative whitespace characters.
The proof-of-concept demonstrates the use of carriage return characters between newlines and backslashes to evade detection.
When pgAdmin processes such files, the regex filter fails to identify the meta-commands, but psql executes them normally, resulting in remote code execution on the pgAdmin host.
The vulnerability can be exploited through multiple whitespace variants, including vertical tabs, form feeds, and bare carriage returns.
Each of these characters is interpreted by psql as valid whitespace or line breaks. Still, the regex pattern fails to match them, creating a dangerous gap between what the filter checks and what the interpreter actually executes.
The pgAdmin development team addressed this vulnerability in version 9.11 by fundamentally changing the security approach.
Instead of relying on regex-based pre-filtering, the updated version launches psql with the restrict directive, which prevents the execution of dangerous meta-commands at the interpreter level.
This architectural improvement moves security enforcement from application-level filtering to native psql restrictions, eliminating the need to track psql’s evolving grammar precisely.
Organizations running pgAdmin four should immediately upgrade to version 9.11 or later to protect against this critical vulnerability.
Additional security measures include treating plain-text restores as high-risk operations, hardening the systems where pgAdmin runs, and implementing comprehensive monitoring and logging for restore operations.
Find this Story Interesting! Follow us on Google News, LinkedIn, and X to Get More Instant Updates
%20(1).webp?fit=1600,900&ssl=1)


