CVE-2025-2945

Published Apr 3, 2025

Last updated a year ago

Overview

AI description

Automated description summarized from trusted sources.

CVE-2025-2945 is a Remote Code Execution (RCE) vulnerability affecting pgAdmin 4 versions prior to 9.2, specifically impacting the Query Tool and Cloud Deployment modules. The vulnerability stems from the insecure handling of user-supplied parameters in two POST endpoints: `/sqleditor/query_tool/download` and `/cloud/deploy`. In these endpoints, the `query_commited` and `high_availability` parameters are passed directly to Python's `eval()` function without proper sanitization. This allows attackers to inject and execute arbitrary code on the server, potentially leading to complete system compromise.

Description
Remote Code Execution security vulnerability in pgAdmin 4 (Query Tool and Cloud Deployment modules). The vulnerability is associated with the 2 POST endpoints; /sqleditor/query_tool/download, where the query_commited parameter and /cloud/deploy endpoint, where the high_availability parameter is unsafely passed to the Python eval() function, allowing arbitrary code execution. This issue affects pgAdmin 4: before 9.2.
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. Spent time digging into CVE-2025-2945 (CVSS 9.9) — an authenticated RCE in #pgAdmin 4's Query Tool via unsafe eval() on a boolean flag. Wrote up the root cause, exploitation logic, and detection guidance here: https://t.co/RAZ079HvvF #CVE #AppSec #RedTeam

    @kainazarkardeh

    29 Aug 2026

    55 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  2. ✅ Web enumeration + Gitea → credentials ✅ CVE-2025-2945 in pgAdmin → RCE ✅ SSH access as svc ✅ Pivoting via ligolo-ng ✅ NFS UID/GID Confusion → access to Docker certs ✅ Docker TLS impersonation → full host access (User Flag) ✅ PWM config tampering + LDAP red

    @0xProcter

    14 Aug 2026

    421 Impressions

    0 Retweets

    14 Likes

    4 Bookmarks

    1 Reply

    0 Quotes

  3. 🛡️ #ExploitGrid Daily #Threat Digest Critical Exploits disclosed today: EGE-GH-M3jqXW0 ( CVE-2024-3094 ) EGE-EDB-iFhaDfa ( CVE-2026-48907 ) EGE-GH-Ixgxp3b ( CVE-2025-59528 ) EGE-GH-eHXL7QB ( CVE-2024-8672 ) EGE-GH-CveopHx ( CVE-2025-2945 ) ..🧵👇

    @exploitgrid

    12 Aug 2026

    45 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    1 Reply

    0 Quotes

  4. 🚨 CVE-2025-2945: Critical 9.9 CVSS pgAdmin 4 Authenticated RCE Cybersecurity https://t.co/XNop8payOL #Infosec #AppSec #RCE #pgAdmin4 #PostgreSQL #CodeInjection #CVE20252945 #PoC #EthicalHacking #BugBounty #PatchNow https://t.co/euFbFueHNG

    @r0otk3r

    12 Jul 2026

    40 Impressions

    0 Retweets

    1 Like

    0 Bookmarks

    0 Replies

    0 Quotes

  5. 🚨 CVE-2025-2945 pgAdmin4 <= 9.1 Authenticated RCE ⚠️ Only for educational purposes & ethical hacking 👍 Like, comment & share if this helped! #CyberSecurity #EthicalHacking #CVE #Exploit #PoC #RedTeam #BugBounty #Infosec #Pentesting #OSCP https://t.co/YKM7W8Ze

    @r0otk3r

    3 Jan 2026

    144 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  6. Critical RCE vulnerability (CVE-2025-2945) found in pgAdmin 4! Upgrade to version 9.2+ immediately to secure your PostgreSQL databases. Link: https://t.co/i7tFKWzSuy #Security #pgAdmin #PostgreSQL #RCE #Database #CVE #Update #Tech #Patch #Software #Exploit #Risk #Protection #IT h

    @dailytechonx

    17 Nov 2025

    35 Impressions

    0 Retweets

    1 Like

    0 Bookmarks

    0 Replies

    0 Quotes

  7. CVE-2025-2945: Remote Code Execution security vulnerability in pgAdmin 4 (Query Tool and Cloud Deployment modules). The vulnerability is associated with the 2 POST endpoints; /sqleditor/query_tool/download, where the query_commited parameter and /cloud/deploy endpoint, where th

    @cyber_advising

    4 Jun 2025

    1029 Impressions

    3 Retweets

    14 Likes

    5 Bookmarks

    0 Replies

    1 Quote

  8. 🚨CVE-2025-2945: pgAdmin 4 Vulnerable to Remote Code Execution FOFA Link: https://t.co/BD05HpTQdS FOFA Query: body="pg-sp-content" && title="pgAdmin 4" Results: 44,485 Advisory: https://t.co/XwUOeznUwF CVSS: 10 https://t.co/El3fiZ34TR

    @DarkWebInformer

    3 Jun 2025

    4128 Impressions

    10 Retweets

    45 Likes

    18 Bookmarks

    1 Reply

    0 Quotes

  9. ⁦@CISAgov⁩ CVE-2025-2945, a severe Remote Code Execution #RCE vulnerability with a CVSS score of #9.9 indicating the highest level of severity. https://t.co/ab4Umz7d7W

    @dateTampaAngel

    13 Apr 2025

    26 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  10. به تازگی برای برنامه pgAdmin که برنامه مدیریت دیتا بیس postgresql می باشد ، آسیب پذیری با کد شناسایی CVE-2025-2945 و از نوع RCE منتشر شده است. نسخه های قبل از 9.1 دارای این آسیب پذیری می باشند و هکرها با ایجاد API های مخرب می توانند کامند اجرا کنند. https://t.co/Poz3aKYxT1 https:

    @AmirHossein_sec

    11 Apr 2025

    14 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  11. 🚨 ALERTĂ - CVE-2025-2945 - Vulnerabilitate critică de securitate cibernetică identificată la nivelul pgAdmin 💡 O vulnerabilitate critică de execuție de cod la distanță (RCE), identificată ca CVE-2025-2945, aplicabilă pentru modulele PostgreSQL Query Tool și Cloud Deployment, h

    @DNSC_RO

    9 Apr 2025

    104 Impressions

    3 Retweets

    2 Likes

    0 Bookmarks

    1 Reply

    0 Quotes

  12. #pgAdmin: Critical pgAdmin #RCE Vulnerability CVE-2025-2945 (CVSS score 9.9) Let Attackers Execute Remote Code - untrusted user input is passed directly to Python’s eval() function 🤦: 👇 https://t.co/CsNCX2fzYd

    @securestep9

    8 Apr 2025

    7 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  13. Remote Code Execution Vulnerability in pgAdmin (CVE-2025-2945) :: Py0zz1 W0r1d https://t.co/hRb4vI6Qte

    @akaclandestine

    8 Apr 2025

    1963 Impressions

    12 Retweets

    28 Likes

    6 Bookmarks

    0 Replies

    0 Quotes

  14. Vulnerabilidad de seguridad crítica en pgAdmin 4, la herramienta de gestión más utilizada para bases de datos PostgreSQL ⚠️ CVE-2025-2945, una grave vulnerabilidad de ejecución remota de código (RCE) con una puntuación CVSS de 9,9 https://t.co/LCd3vuUnGL https://t.co/utGSIZUN2C

    @elhackernet

    8 Apr 2025

    4152 Impressions

    50 Retweets

    80 Likes

    21 Bookmarks

    0 Replies

    0 Quotes

  15. آسیب پذیری بحرانی RCE در pgAdmin4 آسیب پذیری با شناسه ی CVE-2025-2945 در pgAdmin 4 گزارش و اصلاح شده که امکان اجرای کد دلخواه رو به مهاجم میده. https://t.co/bkp2fDRbJo #آسیب_پذیری_امنیتی #RCE #CVE #pgAdmin4

    @onhexgroup

    8 Apr 2025

    146 Impressions

    0 Retweets

    6 Likes

    1 Bookmark

    0 Replies

    0 Quotes

  16. DB管理ツール「pgAdmin」に深刻な脆弱性 - アップデートで修正:Security NEXT https://t.co/5ramhJ84XR ”ユーザー入力を適切に処理せず、外部から任意のコードが実行可能となる…「CVSSv3.1」のベーススコアは、「CVE-2025-2945」が最高値である「10.0」”

    @catnap707

    8 Apr 2025

    171 Impressions

    0 Retweets

    3 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  17. ⚠️ A critical RCE vulnerability (CVE-2025-2945) in pgAdmin has been patched in v9.2. If you're using v9.1 or earlier, update now. Exploitable via malicious API calls. Details: https://t.co/8oXgsBNReT #cybersecurity #PostgreSQL #pgAdmin #infosec

    @threatsbank

    8 Apr 2025

    12 Impressions

    0 Retweets

    1 Like

    0 Bookmarks

    0 Replies

    0 Quotes

  18. CVE-2025-2945 is a critical remote code execution vulnerability affecting pgAdmin 4. Organizations using pgAdmin 4 should upgrade immediately to version 9.2 or later. #ThreatIntel #RedLeggCTI #pgAdmin https://t.co/7Ozkrffuqa

    @RedLegg

    7 Apr 2025

    11 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  19. CVE-2025-2945: Remote Code Execution in pgAdmin 4 https://t.co/sYjzyHbn2f

    @_cvereports

    7 Apr 2025

    11 Impressions

    0 Retweets

    1 Like

    0 Bookmarks

    0 Replies

    0 Quotes

  20. A severe Remote Code Execution (RCE) vulnerability in pgAdmin (CVE-2025-2945), the popular PostgreSQL database management tool, has been patched after researchers discovered attackers could hijack servers through malicious API requests. #cybersecurity https://t.co/6sm4Oe7yeU

    @cybertzar

    7 Apr 2025

    16 Impressions

    0 Retweets

    2 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  21. ⚠️⚠️ CVE-2025-2945 Remote Code Execution Vulnerability in pgAdmin 🎯41k+ Results are found on the https://t.co/pb16tGYaKe nearly year. 🔥PoC: https://t.co/l7BSR2N6AP 🔗FOFA Link:https://t.co/NffRvKC86h FOFA Query:body="pg-sp-content" && title="pgAdmin 4" #OSINT #FOFA

    @fofabot

    7 Apr 2025

    4663 Impressions

    45 Retweets

    113 Likes

    57 Bookmarks

    0 Replies

    0 Quotes

  22. ⚡️The vulnerability details are now available: https://t.co/Yzdm11XElK 🚨🚨pgAdmin 4 Critical Vulnerabilities CVE-2025-2945 (9.9): A wide-open gate to Remote Code Execution—hackers could own your database! CVE-2025-2946 (9.1): XSS attacks lurking in malicious query results, h

    @zoomeye_team

    7 Apr 2025

    1726 Impressions

    3 Retweets

    17 Likes

    10 Bookmarks

    0 Replies

    1 Quote

  23. 🚨 CVE-2025-2945 ⚠️🔴 CRITICAL (9.9) 🏢 https://t.co/EhTSUykEQG - pgAdmin 4 🏗️ 0 🔗 https://t.co/BebFVRMnYl #CyberCron #VulnAlert #InfoSec https://t.co/hFdWZWxVmI

    @cybercronai

    5 Apr 2025

    12 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  24. CVE-2025-2945 Remote Code Execution security vulnerability in pgAdmin 4 (Query Tool and Cloud Deployment modules). The vulnerability is associated with the 2 POST endpoints; /sqled… https://t.co/oET2nzittS

    @CVEnew

    3 Apr 2025

    632 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  25. [CVE-2025-2945: CRITICAL] Critical Remote Code Execution vulnerability discovered in pgAdmin 4 before 9.2. Attackers can execute arbitrary code through POST endpoints. Update immediately to stay secure.#cybersecurity,#vulnerability https://t.co/3T9NiN1Aql https://t.co/qLcVPw6pJN

    @CveFindCom

    3 Apr 2025

    17 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

Configurations

  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.