CVE-2025-12762

Published Nov 13, 2025

Last updated 10 months ago

CVSS critical 9.1
pgAdmin

Overview

AI description

Automated description summarized from trusted sources.

CVE-2025-12762 is a Remote Code Execution (RCE) vulnerability affecting pgAdmin versions up to 9.9. The vulnerability occurs when pgAdmin is running in server mode and performing restores from PLAIN-format dump files. This vulnerability allows attackers to inject and execute arbitrary commands on the server hosting pgAdmin. Successful exploitation could compromise the integrity and security of the database management system and the underlying data.

Description
pgAdmin versions up to 9.9 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
9.8
Impact score
5.9
Exploitability score
3.9
Vector string
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Severity
CRITICAL

Weaknesses

nvd@nist.gov
NVD-CWE-noinfo

Social media

Hype score
Not currently trending

  1. CVE-2025-12762 - Critical RCE in pgAdmin up to v9.9. Attackers can execute arbitrary commands via crafted PLAIN-format dump files. CVSS 9.1. No patch available yet; mitigate immediately. #CVE #pgAdmin #infosec #database #SQL - More: https://t.co/Kw2VVrEU2g

    @HugoValters

    22 May 2026

    264 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  2. #VulnerabilityReport #CommandInjection Critical pgAdmin Flaws (CVE-2025-12762, CVSS 9.1) Allow Remote Code Execution via PostgreSQL Dump Files https://t.co/ckAj78WHrz

    @Komodosec

    22 Dec 2025

    36 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  3. 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

  4. 🚨 A new pgAdmin4 vulnerability, CVE-2025-12762 (CVSS 9.8), allows for RCE in server mode when restoring PLAIN-format dump files. This flaw carries the potential for full system compromise. 🔴 We detect 7,393 instances of potentially exposed hosts at time of writing. 🔴 Ve

    @censysio

    5 Dec 2025

    14570 Impressions

    36 Retweets

    217 Likes

    88 Bookmarks

    2 Replies

    0 Quotes

  5. 🚨 A new pgAdmin4 vulnerability, CVE-2025-12762 (CVSS 9.8), allows for RCE in server mode when restoring PLAIN-format dump files. This flaw carries the potential for full system compromise. 🔴 We observe 14,466 potentially vulnerable instances at time of writing. 🔴 Versio

    @censysio

    4 Dec 2025

    862 Impressions

    4 Retweets

    9 Likes

    3 Bookmarks

    0 Replies

    0 Quotes

  6. ⚠️Vulnerabilidad en pgAdmin ❗CVE-2025-12762 ➡️Más info: https://t.co/OEgRtPrwyc https://t.co/DeEcauXAbj

    @CERTpy

    28 Nov 2025

    98 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  7. 🚨Upozorňujeme na kritickou RCE zranitelnost v pgAdmin, CVE-2025-12762. Pokud aplikace pracuje v režimu server, pak se v ní nachází chyba zabezpečení, kdy při provádění operací obnovení používá výpisové soubory PostgreSQL ve formátu PLAIN. Útočníci mohou v

    @GOVCERT_CZ

    21 Nov 2025

    267 Impressions

    0 Retweets

    1 Like

    0 Bookmarks

    0 Replies

    0 Quotes

  8. pgAdminに深刻な脆弱性4件（CVE-2025-12762, CVSS 9.1）など https://t.co/wo9bLhFa7Q #セキュリティ対策Lab #セキュリティ #Security

    @securityLab_jp

    20 Nov 2025

    10 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  9. 🔴 pgAdmin, Remote Code Execution, #CVE-2025-12762 (Critical) https://t.co/dxPumYx47W

    @dailycve

    19 Nov 2025

    5 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  10. #poc 🎯 CVE-2025-12762 exposes systems running pgAdmin in server mode to remote code execution #pgAdmin #PostgreSQL https://t.co/dyMuZnMYom

    @absholi7ly

    18 Nov 2025

    0 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  11. 🚨🚨CVE-2025-12762 (CVSS 9.1): Critical pgAdmin4 RCE pgAdmin4 server mode + plain backup restore = instant RCE Search by vul.cve Filter👉vul.cve="CVE-2025-12762" ZoomEye Dork👉app="pgAdmin4" 40.3k+ exposed instances ZoomEye Link: https://t.co/l7ZKnjpObB Refer: 1. h

    @zoomeye_team

    17 Nov 2025

    5763 Impressions

    23 Retweets

    74 Likes

    37 Bookmarks

    1 Reply

    0 Quotes

  12. 🚨Alert🚨:CVE-2025-12762 : Critical pgAdmin Flaws Allow Remote Code Execution via PostgreSQL Dump Files. It affects versions up to 9.9. 📊188.5K Services are found on the https://t.co/ysWb28BTvF yearly. 🔗Hunter Link:https://t.co/H4H1mAx3qg 👇Query HUNTER : https://t.co

    @HunterMapping

    17 Nov 2025

    3405 Impressions

    20 Retweets

    61 Likes

    29 Bookmarks

    0 Replies

    0 Quotes

  13. ⚠️ Critical pgAdmin4 Vulnerability Lets Attackers Execute Remote Code on Servers Read more: https://t.co/OlfREXflVU A severe remote code execution (RCE) flaw has been uncovered in pgAdmin4, the popular open-source interface for PostgreSQL databases. Dubbed CVE-2025-12762,

    @The_Cyber_News

    17 Nov 2025

    4403 Impressions

    31 Retweets

    89 Likes

    22 Bookmarks

    0 Replies

    2 Quotes

  14. pgAdmin patched four flaws. The Critical RCE (CVE-2025-12762) risks arbitrary code execution via malicious PostgreSQL dump files. LDAP Injection (CVE-2025-12764) and TLS Bypass were also fixed. Update to v9.10. #pgAdmin #RCE #Cybersecurity #PostgreSQL https://t.co/2smCTmL72d

    @Daily_CyberSec

    17 Nov 2025

    24 Impressions

    1 Retweet

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  15. CVE-2025-12762 - Exploit and Reproduction for pgAdmin4 vulnerable to Remote Code Execution (RCE) when running in server mode #pruva reproduction: https://t.co/rt2E1Cf7kN Advs: https://t.co/PQsGAMMpCU

    @N3mes1s

    14 Nov 2025

    4069 Impressions

    15 Retweets

    55 Likes

    27 Bookmarks

    1 Reply

    0 Quotes

  16. 🚨 pgAdmin < 9.10 has an RCE vulnerability (CVE-2025-12762) allowing attackers to execute arbitrary commands on the server, risking the database system's integrity and security. https://t.co/4S73FCs7tI https://t.co/MNR03JdEds

    @IntCyberDigest

    14 Nov 2025

    7873 Impressions

    23 Retweets

    64 Likes

    20 Bookmarks

    0 Replies

    1 Quote

  17. CVE-2025-12762 pgAdmin versions up to 9.9 are affected by a Remote Code Execution (RCE) vulnerability that occurs when running in server mode and performing restores from PLAIN-form… https://t.co/MqbRbvmUM6

    @CVEnew

    13 Nov 2025

    145 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  18. [CVE-2025-12762: CRITICAL] Critical Remote Code Execution (RCE) vulnerability in pgAdmin versions up to 9.9 allows attackers to execute arbitrary commands, posing a severe threat to cyber security.#cve,CVE-2025-12762,#cybersecurity https://t.co/qhfmldF6k4 https://t.co/iyNLblD59Y

    @CveFindCom

    13 Nov 2025

    57 Impressions

    0 Retweets

    0 Likes

    1 Bookmark

    0 Replies

    0 Quotes

  19. CVE-2025-12762 is a critical pgAdmin 4 RCE (CVSS 9.1) affecting versions ≤9.9. Network-accessible, low complexity, requires only low privs. The Changed Scope (S:C) rating means compromise extends beyond pgAdmin itself. Attack surface: Restore module processing PLAIN-format

    @gothburz

    13 Nov 2025

    619 Impressions

    1 Retweet

    7 Likes

    5 Bookmarks

    0 Replies

    0 Quotes

  20. **CVE-2025-12762** is a critical Remote Code Execution (RCE) vulnerability affecting **pgAdmin** versions up to 9.9. when operating in server mode, specifically during the restore process from PLAIN-format dump files. The vulnerability allows an attacker to inject malicious

    @CveTodo

    13 Nov 2025

    32 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

Configurations

Related CVEs

  1. 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
  2. The per-tool permission system (custom roles / role-based tool permissions, introduced in pgAdmin 4 9.3) did not enforce its permission check consistently. In SERVER mode, pgAdmin 4 gates each tool behind a per-tool Flask-Security permission, but the permission decorator (permissions_required) was applied only to a single "front door" route per tool. Every other backend route and Socket.IO handler in that tool's workflow relied solely on pga_login_required/socket_login_required, which check authentication but not the tool permission. The reporter verified three cases against a test build: (1) a user without tools_query_tool permission received 403 on the protected sqleditor initialization route, but the same session went on to connect the server, initialize the viewdata backend chain, and retrieve real table row content; (2) a user without tools_grant_wizard received 403 on the protected acl route, but the same session still enumerated grantable objects, generated GRANT SQL, and successfully applied it -- confirmed database-side via has_table_privilege(); (3) a user without tools_schema_diff received 403 on the protected panel route, but the same session initialized schema diff, enumerated and connected databases, and obtained real DDL differences via the compare_database Socket.IO handler. The reporter also confirmed a related but distinct issue: a non-owner triggering /misc/workspace/adhoc_connect_server against an administrator-owned shared server caused pgAdmin to persist a new server row still owned by the administrator (user_id/shared unchanged from the source), even though the connection attempt itself reported failure. During remediation, the same front-door-only permission gap was found to also affect the ERD, PSQL, and Debugger tools, and the Backup, Restore, Maintenance, and Import/Export blueprints, none of which were part of the original report; these were fixed using the same pattern as an extension of the reported defect class. An authenticated user who had valid pgAdmin login and a stored, working database connection, but had been explicitly denied a specific tool's permission by an administrator, could therefore still drive that tool end-to-end through its other routes and sockets, including obtaining an interactive psql session over the /pty Socket.IO namespace and invoking backup/restore/maintenance/import-export jobs. Because the bypass only restores access to tools operating over the user's own already-authenticated database connection, it does not grant the user any database privilege they did not already hold; it circumvents pgAdmin's own tool-level access-control policy (an organisational segregation-of-duties control, separate from database-level authorization), letting a user reach a pgAdmin feature an administrator intended to withhold from them, using capabilities their existing database role already permits through other means. Socket.IO event handlers had no permission-aware equivalent of permissions_required; only socket_login_required existed, checking authentication but not the tool permission. Fix adds a socket_permissions_required decorator (mirroring permissions_required, honouring the Administrator bypass, reading permissions via has_permission()) and applies it, alongside permissions_required, as the outermost decorator on every backend route and Socket.IO handler for the affected tools. Regression tests assert 403 on every gated route and socket handler for a permission-less user. This issue affects pgAdmin 4 in SERVER mode: from 9.3 before 9.17.•CVE-2026-17350
  3. /misc/workspace/adhoc_connect_server, part of the Workspaces feature introduced in pgAdmin 4 9.0, when passed the id of an existing server, clones that server via Server.clone(), which copies every column from the source row, including user_id, shared, shared_username, and the stored credential fields password, save_password, and tunnel_password. When a non-owner triggered an adhoc connect against another user's (in practice, typically an administrator's) shared server, the clone inherited that user's ownership, shared flag, and stored database credentials verbatim. pgAdmin persisted this cross-tenant, credential-bearing server row before the connection was even attempted, so it survived even when the connection subsequently failed. The non-owner could then open the newly-owned clone and pgAdmin would connect using the source user's stored database password on the non-owner's behalf, granting the non-owner use of database credentials -- and whatever database privileges they confer -- that were never their own. Fix forces the cloned adhoc record's ownership fields (user_id, shared, shared_username) and stored credential fields (password, save_password, tunnel_password) to belong to the calling user and be cleared/private before committing, regardless of the source server's ownership, sharing state, or stored credentials. A regression test asserts that an adhoc connect triggered by a non-owner against another user's shared server persists a row owned by the caller, not shared, and without the source's stored credentials. This issue affects pgAdmin 4: from 9.0 before 9.17.•CVE-2026-17349
  4. In SERVER mode, pgAdmin 4 enforces authentication per route via the @pga_login_required decorator; the application's before_request hook only handles desktop-mode auto-login and the Kerberos/Webserver-auth redirect, so any route shipped without the decorator is reachable without authentication (CWE-306). This is the same defect class previously fixed as CVE-2026-12046 (the sqleditor close/update_connection routes). A follow-up sweep, prompted by a report describing an incomplete fix for CVE-2026-12046, found further routes missing @pga_login_required: the Constraints blueprint's nodes and proplist (object listing) routes and its delete route (a state-mutating DELETE that removes table constraints); preferences.get_all_cli (GET, discloses all CLI-settable preference values); debugger.close (DELETE); and schema_diff.close (DELETE). An unauthenticated network client could therefore enumerate constraint metadata, delete table constraints, read preference values, and force-close debugger or schema-diff sessions belonging to other users, without ever authenticating. Fix adds the missing @pga_login_required decorator (and the corresponding import to the Constraints module) to each of these routes. The change is decorator-only; no behavioral changes to the underlying handlers. This issue affects pgAdmin 4 in SERVER mode: the Constraints and Debugger routes from 1.0, the Schema Diff close route from 4.18, and preferences.get_all_cli from 8.2, all before 9.17.•CVE-2026-17348
  5. The fix for CVE-2026-12045 in pgAdmin 4 9.16 required the LLM-supplied query passed to the AI Assistant's execute_sql_query tool to parse, via sqlparse, as exactly one non-transaction-control statement before running it inside a BEGIN TRANSACTION READ ONLY wrapper. sqlparse's string-literal lexing can disagree with PostgreSQL's own parser: under standard_conforming_strings = on (PostgreSQL's default since 9.1), a backslash immediately before a quote is an ordinary character to PostgreSQL, but sqlparse treats it as escaping the quote. A payload such as SELECT '\';COMMIT;CREATE TABLE pwn(x int);SELECT 1 --' therefore parses as a single SELECT to sqlparse's validator, while PostgreSQL executes it as four statements: the smuggled COMMIT ends the wrapping read-only transaction, and the trailing ROLLBACK becomes a no-op. This reintroduces the same write/RCE bypass CVE-2026-12045 was meant to close, reachable via the same indirect prompt-injection delivery (an attacker plants the payload in any object the AI Assistant may read; the LLM emits it as a tool call). An initial candidate fix ran the query with psycopg's execute(..., prepare=True), intending to force PostgreSQL's own Parse step (extended query protocol) to reject multi-statement text regardless of sqlparse's classification. This candidate fix does not work as submitted: psycopg3's PrepareManager silently ignores the prepare argument whenever the connection's prepare_threshold is None, which is pgAdmin's default for every server connection (the per-server "Prepare threshold" field is blank unless an administrator explicitly sets it) -- psycopg3 falls back to the simple query protocol, the same multi-statement-capable path the bypass exploits, so the candidate fix closes nothing on any real-world default configuration. The corrected fix sets conn.prepare_threshold = 0 directly on the dedicated, single-use read-only connection the AI Assistant tool opens, structurally forcing the extended query protocol independent of any server-level configuration. Verified against a live PostgreSQL 18 instance: the payload executes successfully under the prepare_threshold=None (default) behavior, and is rejected with "cannot insert multiple commands into a prepared statement" once prepare_threshold=0 is set on that connection. This issue affects pgAdmin 4: from 9.13 before 9.17.•CVE-2026-17351

References

Sources include official advisories and independent security research.