CVE-2025-13780

Published Dec 11, 2025

Last updated 10 months ago

CVSS critical 9.1
pgAdmin

Overview

AI description

Automated description summarized from trusted sources.

CVE-2025-13780 is a remote code execution (RCE) vulnerability affecting pgAdmin versions up to 9.10. It occurs when running in server mode and performing restores from PLAIN-format dump files. The vulnerability stems from the application's "regex firewall" failing to properly filter out dangerous psql meta-commands, which can execute operating system commands. Attackers can inject and execute arbitrary commands on the server hosting pgAdmin by bypassing the regex filter with strategically placed whitespace characters in SQL files. These whitespace characters, such as carriage returns, are recognized by psql but not by the regex filter, allowing malicious code to be executed during database restoration. pgAdmin version 9.11 addresses this vulnerability.

Description
pgAdmin versions up to 9.10 are affected by a Remote Code Execution (RCE) vulnerability that occurs when running in server mode and performing restores from PLAIN-format dump files. This issue allows attackers to inject and execute arbitrary commands on the server hosting pgAdmin, posing a critical risk to the integrity and security of the database management system and underlying data.
Source
f86ef6dc-4d3a-42ad-8f28-e6d5547a5007
NVD status
Analyzed
Products
pgadmin_4

Risk scores

CVSS 3.1

Type
Primary
Base score
8.8
Impact score
5.9
Exploitability score
2.8
Vector string
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Severity
HIGH

Weaknesses

134c704f-9b21-4f2e-91b3-4a467353bcc0
CWE-94

Social media

Hype score
Not currently trending

  1. pgAdmin 4で重大(Critical)な脆弱性3件が修正。CVE-2026-17566はCVSSスコア9.9で、Import/Export Dataクエリでのバックスラッシュの取扱不一致に起因する遠隔コード実行。CVE-2025-13780横並び。CVE-2026-17349はCVSSスコア9.6で、アド

    @__kokumoto

    5 Aug 2026

    1035 Impressions

    1 Retweet

    4 Likes

    2 Bookmarks

    0 Replies

    0 Quotes

  2. #VulnerabilityReport #CVE202513780 Critical pgAdmin RCE (CVE-2025-13780) Flaw Bypasses Fix, Allowing Server Takeover Via Malicious Database Restore https://t.co/wWJB28tVYV

    @Komodosec

    20 Jan 2026

    69 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  3. https://t.co/cOg33vG2NJ When Regex Isn’t Enough: How We Discovered CVE-2025-13780 in pgAdmin

    @BentleyAudrey

    18 Dec 2025

    614 Impressions

    2 Retweets

    12 Likes

    2 Bookmarks

    0 Replies

    0 Quotes

  4. 🚨 Critical RCE in pgAdmin 4 (≤ v9.10): CVE-2025-13780 Bypasses regex filter on PLAIN dump restores using whitespace tricks – attackers run arbitrary shell commands! Patch to v9.11+ NOW if in server mode. Details: https://t.co/sCMfayJyLg #CyberSecurity #PostgreSQL #pgAd

    @Manikandanbas03

    17 Dec 2025

    71 Impressions

    0 Retweets

    2 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  5. pgAdmin に深刻な脆弱性(CVE-2025-13780) https://t.co/TaqaY4BdZ1 #セキュリティ対策Lab #セキュリティ #Security

    @securityLab_jp

    17 Dec 2025

    268 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  6. 🚨Alert🚨:CVE-2025-13780 : pgAdmin are Affected by A Remote Code Execution (RCE) Vulnerability. It affects versions up to 9.10. 🔥PoC :https://t.co/G6VnT4AarK 📊189.9K Services are found on the https://t.co/ysWb28Crld yearly. 🔗Hunter Link:https://t.co/H4H1mAxBfO 👇Qu

    @HunterMapping

    16 Dec 2025

    9845 Impressions

    28 Retweets

    128 Likes

    73 Bookmarks

    2 Replies

    1 Quote

  7. When Regex Isn’t Enough: How We Discovered #CVE-2025-13780 in #pgAdmin https://t.co/K2FQ188m2O

    @kmkz_security

    16 Dec 2025

    3316 Impressions

    7 Retweets

    33 Likes

    13 Bookmarks

    0 Replies

    0 Quotes

  8. Vulnerabilidad crítica en pgAdmin La herramienta de gestión de bases de datos PostgreSQL de código abierto ⚠️ CVE-2025-13780 https://t.co/BBjhwrNxsb https://t.co/FIrk8BLNcG

    @elhackernet

    15 Dec 2025

    4910 Impressions

    20 Retweets

    70 Likes

    20 Bookmarks

    0 Replies

    0 Quotes

  9. ⚠️ pgAdmin Vulnerability Let Attackers Execute Shell Commands on the Host Source: https://t.co/qS356B6pRI A severe security vulnerability has been uncovered in pgAdmin 4, the popular open-source PostgreSQL database management tool. Tracked as CVE-2025-13780, this critical

    @The_Cyber_News

    15 Dec 2025

    3770 Impressions

    28 Retweets

    93 Likes

    13 Bookmarks

    0 Replies

    1 Quote

  10. CVE-2025-13780 Critical pgAdmin Vulnerability Let Attackers Execute Shell Commands on the Host Read the full report on - https://t.co/mt5uGjeuP6 https://t.co/ry4ejP5Jiw

    @cyberbivash

    15 Dec 2025

    8 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  11. pgAdmin 4 flaw CVE-2025-13780 allows remote code execution via crafted restore files, letting attackers run shell commands on host systems. Users should patch or mitigate immediately. #RCE https://t.co/Cc36e9Szc9

    @threatcluster

    15 Dec 2025

    49 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  12. 🚨🚨 CVE-2025-13780 (CVSS: 9.1): pgAdmin4 Meta-Command Filter Command Execution pgAdmin 4 < 9.11 fails to detect meta-commands when a SQL file starts with UTF-8 BOM, leading to remote command execution during restore. 🔥 PoC: https://t.co/XRlUUB3arH Search by vul.cve ht

    @zoomeye_team

    15 Dec 2025

    11244 Impressions

    41 Retweets

    163 Likes

    85 Bookmarks

    2 Replies

    3 Quotes

  13. CVE-2025-13780 pgAdmin versions up to 9.10 are affected by a Remote Code Execution (RCE) vulnerability that occurs when running in server mode and performing restores from PLAIN-for… https://t.co/eN4ZOX04MU

    @CVEnew

    13 Dec 2025

    181 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  14. PgAdmin4 affected by Meta-Command Filter Command Execution (CVE-2025-13780). Update to the latest secure version to prevent system compromise. https://t.co/yXqB43Oqty

    @pulsepatchio

    13 Dec 2025

    7 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  15. GitHub - zeropwn/pgadmin4-9.10-CVE-2025-13780: Proof of concept for CVE-2025-13780 - https://t.co/BhEuTnddz5

    @piedpiper1616

    12 Dec 2025

    1627 Impressions

    5 Retweets

    14 Likes

    7 Bookmarks

    0 Replies

    0 Quotes

  16. in november, i reported an RCE that bypassed the patch for CVE-2025-12762 in versions 9.10 of pgadmin4. it has now been patched in the latest release 9.11 and tracked as CVE-2025-13780 https://t.co/o8fxY6XKYO

    @zer0pwn

    11 Dec 2025

    477 Impressions

    0 Retweets

    7 Likes

    1 Bookmark

    0 Replies

    0 Quotes

  17. [CVE-2025-13780: CRITICAL] Critical Remote Code Execution vulnerability discovered in pgAdmin versions up to 9.10 when restoring PLAIN-format dump files in server mode. Attackers can inject and execute comma...#cve,CVE-2025-13780,#cybersecurity https://t.co/eLUgbdlqHQ https://t.c

    @CveFindCom

    11 Dec 2025

    19 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

Configurations

Related CVEs

  1. pgAdmin 4's Backup tool appended the client-supplied 'database' field from the /backup/job/<sid>/object request to the pg_dump argument vector as a bare trailing positional argument, without validation. Because pg_dump parses its options with getopt_long, which permutes arguments, a value beginning with a dash was interpreted as an option rather than as a database name. A value such as --file=/absolute/path therefore overrode the storage-confined --file that pgAdmin had constructed earlier, causing pg_dump to write its output anywhere the pgAdmin process could write, outside the user's File Manager storage directory. This yields arbitrary file creation and overwrite as the operating-system account running pgAdmin, which can destroy pgAdmin's own configuration database and, depending on the target chosen, be escalated further. The same field additionally permitted connection-string injection. libpq expands a database name containing an equals sign into a full connection string, and keywords embedded there override the --host and --port that pgAdmin passes, so a value such as 'host=attacker.example port=5432 dbname=x' redirected pg_dump to a server of the attacker's choosing. Because pgAdmin exports the decrypted stored database password in the PGPASSWORD environment variable before executing the utility, the redirected connection carries that credential to the attacker-nominated endpoint. Both behaviours are reachable by any authenticated user holding the tools_backup permission, which is granted to the default User role. The fix stops passing the database name through the argument vector altogether and supplies it in the PGDATABASE environment variable, which libpq treats as a literal database name and never expands as a connection string. This matches the approach already used by the Import/Export tool. Regression tests assert that the database name is absent from the constructed argument vector and that PGDATABASE carries the exact requested value. This issue affects pgAdmin 4: from the introduction of the trailing positional database argument in the Backup tool before 9.18.•CVE-2026-86864
  2. pgAdmin 4's File Manager save_file endpoint, which backs saving from the Query Tool and ERD, validated the requested path with Filemanager.check_access_permission() and then opened the file for writing with a plain open() call. CVE-2026-7819 had previously hardened the separate file upload path by opening its target with O_NOFOLLOW, so that the kernel refuses to follow a symbolic link at the final path component, but save_file was left on an unprotected open(). A symbolic link already present when the check ran was rejected by the check itself; the remaining exposure was a link substituted at the final path component in the interval between the check and the write, at which point the write followed the link and landed outside the user's storage directory, creating or overwriting an arbitrary file as the operating-system account running pgAdmin. Exploitation requires the ability to create or replace a symbolic link inside the requesting user's storage directory. pgAdmin exposes no interface that creates symbolic links, so this requires filesystem access to the pgAdmin host or to a shared or network-mounted storage backend, together with winning the timing window. The reporter did not achieve a write against a released version, having attempted approximately 63,000 racing requests without success; the reported defect is the uncovered write path rather than a demonstrated sandbox escape. The fix routes save_file's write through the same O_NOFOLLOW-protected helper already used by the upload path, so both File Manager write sinks carry identical kernel-enforced protection, and reports a symbolic-link refusal explicitly instead of surfacing the underlying system error text. Note that files created by save_file are now given mode 0600, inheriting the behaviour introduced for uploads. The protection covers the final path component; substitution of an intermediate directory component is not addressed by this change. This issue affects pgAdmin 4: from the introduction of the containment check in the File Manager save path before 9.18.•CVE-2026-86861
  3. pgAdmin 4's Restore and Maintenance tools passed the client-supplied 'database' field directly as the value of the --dbname option given to pg_restore and psql. libpq expands a database name containing an equals sign into a full connection string, and connection keywords embedded in that value take precedence over the --host and --port arguments that pgAdmin supplies. A value such as 'host=attacker.example port=5432 dbname=x' therefore redirected the utility to a server chosen by the requesting user rather than the server the operation was invoked against. Because pgAdmin exports the decrypted stored database password in the PGPASSWORD environment variable before executing the utility, the redirected connection presents that credential to the attacker-nominated endpoint, which may capture it. The redirection additionally permits outbound connections from the pgAdmin host to arbitrary network addresses, including hosts not otherwise reachable by the requesting user. The behaviour is reachable by any authenticated user holding the tools_restore or tools_maintenance permission, both of which the default User role grants. The Maintenance tool was not affected in the earliest releases, where the value was wrapped by a quoting helper that incidentally prevented expansion; it became affected when that wrapper was removed. The fix supplies the target database in the PGDATABASE environment variable, which libpq treats as a literal database name and never expands as a connection string. Where pg_restore requires a --dbname argument to be present, an empty value is passed, which contains no equals sign and is therefore not expanded, while the real name is taken from the environment. This issue affects pgAdmin 4: from the introduction of the --dbname argument in the Restore and Maintenance tools before 9.18.•CVE-2026-86862
  4. pgAdmin 4's Webserver authentication source is intended to accept an identity asserted by the web server or reverse proxy in front of pgAdmin, delivered through the WSGI/CGI environment. WebserverAuthentication.get_user() read config.WEBSERVER_REMOTE_USER from request.environ and, when that returned nothing, fell back to reading the same name directly from the inbound HTTP request headers via request.headers.get(). An inbound HTTP header is written by whoever sends the request, so any client able to reach pgAdmin could supply that header itself and be authenticated as any username it named, including an existing Administrator, without presenting a password or any other credential. The environment lookup could also be satisfied by a client-supplied header whenever WEBSERVER_REMOTE_USER was configured to an HTTP_-prefixed or hyphenated name such as HTTP_X_FORWARDED_USER or X-Forwarded-User, since WSGI servers place inbound headers into the environment under exactly those names. Deployments are affected only when 'webserver' is enabled in AUTHENTICATION_SOURCES. The fix distinguishes a genuine CGI/WSGI variable from a header-derived one and implicitly trusts only the former. A header-asserted identity is now accepted only when the operator explicitly opts in via WEBSERVER_REMOTE_USER_FROM_HEADER, the request arrives from a peer listed in WEBSERVER_TRUSTED_PROXIES, and, when configured, a shared secret supplied in WEBSERVER_SHARED_SECRET_HEADER matches WEBSERVER_SHARED_SECRET under a constant-time comparison. The trusted-peer check deliberately reads the real socket peer address rather than request.remote_addr, because ProxyFix rewrites the latter from the client-controlled X-Forwarded-For header and would otherwise allow an attacker to claim to be the trusted proxy. As defence in depth, login() now refuses any account whose auth_source is not 'webserver', so a misconfigured trust gate cannot be used to assume an internal or LDAP account. This issue affects pgAdmin 4: from 6.2 before 9.18.•CVE-2026-86863
  5. pgAdmin 4's Import/Export Data tool builds a psql \copy (...) command line by interpolating a user-supplied SQL query into a Jinja template and passing the rendered line to psql via --command. To stop an attacker from breaking out of the (...) wrapper, create_import_export_job() (route POST /import_export/job/<sid>, gated only by the ordinary, commonly-granted tools_import_export_data permission) validated the query with a hand-written parenthesis-balance checker, _is_query_parens_balanced(). That checker always treated a backslash before a single quote (\') as escaping the quote, i.e. as if standard_conforming_strings were off. PostgreSQL has defaulted standard_conforming_strings to on since 9.1 (2010), the default on every PostgreSQL version pgAdmin 4 currently supports (13-18); under that default psql's own \copy tokenizer treats \ as an ordinary character, so a single quote immediately after it closes the string literal. A query such as SELECT 'a\') TO PROGRAM 'echo pwned' x' was therefore accepted as "balanced" by pgAdmin's checker (which believed the ) was still inside the string), while psql, run through the actual rendered command line, closes the string at that point and treats the following ) as the end of the wrapping \copy (...) subquery, exposing an attacker-chosen TO PROGRAM '<command>' clause that psql executes via popen() -- independent of a subsequent syntax error later on the same line. This is the same class of bug as CVE-2025-12762/CVE-2025-13780 (RCE via psql meta-command/COPY injection during PLAIN-format dump restore), reached through an independently written defense in a different module (Import/Export Data rather than Restore) that had its own, different logic bug (inverted backslash-escape semantics rather than a BOM-defeated regex anchor). The fix rejects any backslash inside a single-quoted string in the query outright, rather than picking one of the two possible psql interpretations. This is intentionally conservative: because the correct interpretation of \ depends on the target server's standard_conforming_strings setting, which the checker cannot reliably know at validation time, refusing the query is safer than guessing. This issue affects pgAdmin 4: from the introduction of _is_query_parens_balanced() before 9.18.•CVE-2026-17566

References

Sources include official advisories and independent security research.