pgAdmin 4 vulnerabilities

pgAdmin 4 before 9.19 contains a bypass of the CVE-2026-17566 fix in the Import/Export Data tool. Improper validation of a backslash inside a double-quoted identifier hides a closing parenthesis and executes a TO PROGRAM clause via psql on the pgAdmin host with the OS account privileges.

In pgAdmin 4, the 'webserver' authentication source was vulnerable because WebserverAuthentication.get_user() fell back to reading the username directly from inbound HTTP request headers when the WSGI/CGI environment lookup returned nothing. As a result, any client able to reach pgAdmin could supply that header itself and authenticate as any username, including an existing Administrator, without a password. The issue affects versions from 6.2 before 9.18 and only applies when 'webserver' is enabled in AUTHENTICATION_SOURCES.

A vulnerability in pgAdmin 4 allows remote code execution (RCE) via injection into the Import/Export Data tool. The validation function incorrectly handles backslashes in SQL strings, enabling bypass of protections and addition of a TO PROGRAM clause to psql commands.

A vulnerability in pgAdmin 4 (versions 9.13 to 9.16) allows bypassing the CVE-2026-12045 fix by injecting SQL queries into the AI assistant. An attacker can plant a malicious payload in an object read by the assistant, leading to execution of multiple SQL statements, including write or remote code execution.

In the adhoc_connect_server function in pgAdmin 4 9.0-9.16, when a non-owner user clones a server, all columns including credentials (passwords) and ownership flags are copied. This allows an attacker to take over the cloned server and use database passwords belonging to another user (e.g., an administrator).

A stored cross-site scripting vulnerability exists in pgAdmin 4 versions 6.0 through 9.15. Text returned by a PostgreSQL server (e.g., object names in errors or EXPLAIN fields) was passed verbatim to html-react-parser, allowing injection of arbitrary HTML, including iframes. An attacker controlling the server or creating a maliciously named object can hijack the victim's pgAdmin session.

In pgAdmin 4 versions 6.9 through 9.15, two SQL Editor endpoints lack authentication decorators, allowing unauthenticated attackers to trigger pickle deserialization from server sessions. Exploitation requires additional preconditions (knowledge of SECRET_KEY and write access to sessions directory) to achieve remote code execution.

A vulnerability in the pgAdmin 4 AI Assistant allows an attacker who can influence database content read by the assistant to execute arbitrary SQL with the privileges of the pgAdmin user's database role. The flaw stems from missing validation of LLM-generated queries, enabling bypass of read-only mode via injection of commands like COMMIT or ROLLBACK.

In pgAdmin 4 server mode, multiple endpoints fetched user-owned objects without filtering by the requesting user's identity, allowing an authenticated user to access another user's private servers, server groups, background processes, and debugger arguments by guessing object IDs. The Shared Servers feature had additional issues including credential leakage, privilege escalation via writable passexec_cmd enabling arbitrary command execution, and owner-data corruption.

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.

pgAdmin versions up to 9.9 are affected by a Remote Code Execution (RCE) vulnerability when running in server mode and performing restores from PLAIN-format dump files. Attackers can inject and execute arbitrary commands on the server hosting pgAdmin.

In pgAdmin 4, materialized view refresh passed the target database name to psql's --dbname argument unchanged. libpq treats a value containing "=" or a postgresql:// URI as a full connection string, allowing redirection to a chosen host and port and disclosure of the saved server password.

In pgAdmin 4, changing a user's password (by the user or an administrator) did not invalidate existing sessions. A session established before the change, e.g. on another device or by someone with the old password, stayed logged in until it expired.

In server mode pgAdmin 4 validated a user-supplied file path in the storage directory with check_access_permission() and then opened it by name using a plain open() or passed the path to utilities (pg_dump, pg_dumpall, pg_restore, psql) and to servers.json export/import and import file listing. Swapping in a symbolic or hard link or a FIFO between the check and the open redirected the operation outside the storage directory, allowing a file to be written, overwritten or read, or loaded into a table, as the pgAdmin operating-system account. This affects pgAdmin 4 before 9.19.

In pgAdmin 4 server mode before 9.19, get_complete_file_path() only stripped leading slashes before joining paths, so a path such as ../<another user>/.pgpass could name another user's file. The sslkeylogfile parameter was passed to libpq unchanged, and make_conninfo() quoted parameter values but not names, allowing additional keyword=value pairs to be smuggled in.

In pgAdmin 4 server mode, the server API create and update endpoints stored the "shared" flag and shared username, letting any user able to register a server share it with everyone. The servers.json import had a similar gap, as a non-administrator's "Shared" entries were removed only after validation.

In pgAdmin 4 before 9.19, when a server had no password file, client certificate, or client key configured, or the configured file could not be found, pgAdmin omitted the parameter and libpq fell back to the defaults of the operating-system account running pgAdmin. In server mode any user could therefore connect using the service account's saved passwords or client certificate.

In pgAdmin 4, the server password was written into pgAdmin's own process environment (as PGPASSWORD for the PSQL tool and under a per-process variable for a utility) and never removed. In server mode the environment is shared across all users' requests and copied into started processes, so another user could inherit the password and use it to connect.

In pgAdmin 4 server mode, libpq looks up connection services in the service file of the operating-system account, allowing users to use that account's credentials or certificate files. The vulnerability affects versions before 9.19 and can lead to unauthorized access to database servers.

In pgAdmin 4 server mode, removing KRB5CCNAME caused the Kerberos library to fall back to the service account's default credential cache, allowing any user to connect as the service principal. The vulnerability affects versions before 9.19 and also includes bypassing gssencmode=disable and SSPI behavior on Windows.

In pgAdmin 4 server mode, the user-set binary path was not checked against SHARED_STORAGE directories, allowing an executable to be uploaded and run as the pgAdmin service account. The vulnerability is especially relevant on Windows where files can be executable, and affects versions before 9.19.

In pgAdmin 4 server mode, the sshtunnel library always loaded unencrypted private keys from the service account's ~/.ssh and read its SSH configuration, allowing any user to configure a tunnel using the service account's identity. The vulnerability affects versions before 9.19.

In pgAdmin 4 server mode, a path validation flaw exists: check_access_permission() validated one path while callers acted on a differently constructed path, allowing files outside the user's storage directory to be read, written, deleted, or moved. Additionally, double-decoding of folder paths and missing separators when joining paths enabled access to other users' directories or the entire host filesystem. The issue affects pgAdmin 4 before 9.19 and does not affect desktop mode.

In server mode, pgAdmin 4 keeps an account per authentication source, so the same username can exist as both an internal and an LDAP account. After LDAP or Kerberos authentication, pgAdmin selected the account to log in by username alone, without verifying that it came from the source that authenticated the user, allowing session takeover of another account with its role, servers, and saved database passwords.

In pgAdmin 4 server mode, the internal account lockout after MAX_LOGIN_ATTEMPTS failed logins (3 by default) could be bypassed in several ways. Flaws in Flask-Security views, case-sensitive username lookup, and interaction with other authentication sources (LDAP, webserver, Kerberos) allow an unauthenticated attacker unlimited password guesses against any internal account, including the administrator's. Additionally, unauthorized password resets and server configuration disclosure in the About box are possible.

In pgAdmin 4's Backup tool, the client-supplied database name was passed to pg_dump as a bare trailing positional argument without validation. Because pg_dump parses options with getopt_long, which permutes arguments, a value beginning with a dash (e.g. --file=/path) was treated as an option, overriding the previously set --file and allowing files to be written outside the File Manager storage directory. The same field also allowed connection-string injection, redirecting pg_dump to an attacker-controlled server along with the database password from the PGPASSWORD environment variable.

The vulnerability in pgAdmin 4 affects the Restore and Maintenance tools, which pass the 'database' field directly as the --dbname argument to pg_restore and psql. A value containing an equals sign is expanded by libpq into a full connection string, potentially redirecting the connection to an attacker-controlled server. This can lead to disclosure of the decrypted stored database password and enable outbound connections from the pgAdmin host to arbitrary network addresses.

In pgAdmin 4, the File Manager save_file endpoint validated the requested path with Filemanager.check_access_permission() and then opened the file for writing with a plain open() call, without O_NOFOLLOW. As a result, if the final path component was replaced with a symbolic link in the interval between the check and the write, the write followed the link and could create or overwrite an arbitrary file as the operating-system account running pgAdmin. This affects pgAdmin 4 from the introduction of the containment check in the File Manager save path before 9.18.

The role-based tool permission system in pgAdmin 4 (versions 9.3-9.17) lacked consistent enforcement. The permissions_required decorator was applied only to the main route of each tool, while other backend routes and Socket.IO handlers only checked authentication, not the specific tool permission. This allowed an authenticated user without the required permission to fully use the tool (e.g., psql, backup, restore) via alternative paths.

pgAdmin 4 in SERVER mode has a vulnerability where some routes lack required authentication. An unauthenticated network client can enumerate constraint metadata, delete table constraints, read preference values, and force-close debugger or schema-diff sessions belonging to other users.

In pgAdmin 4 from version 7.2 before 9.17, the MASTER_PASSWORD_HOOK setting allowed shell command injection via a username containing shell metacharacters (e.g., ';', '$()', backticks). The username from external auth sources (OAuth, Kerberos) could be used to execute arbitrary commands as the pgAdmin service account.

A vulnerability in pgAdmin 4 allows SQL injection via improper escaping of object names in query templates. A low-privileged user can create an object with an apostrophe in its name, which when another user opens the Statistics or Dependencies tab leads to arbitrary SQL execution in the database session.

SQL injection vulnerability in pgAdmin 4's named restore point endpoint (POST /browser/server/restore_point/{gid}/{sid}). The user-supplied 'value' field was interpolated directly into the SQL string with str.format() instead of being passed as a bound parameter, allowing an authenticated pgAdmin user with a connected PostgreSQL session to inject additional statements through that endpoint.

Open redirect vulnerability in pgAdmin 4's multi-factor authentication flow. The MFA validate and register endpoints honored the user-supplied 'next' parameter without confirming the target points back to pgAdmin, allowing an authenticated user to be redirected to an external attacker-controlled host.

HTML injection vulnerability in pgAdmin 4's cloud module allows injecting HTML code via crafted credentials. The flaw exists in /rds/, /azure/, /google/, and /cloud/ endpoints where SDK error messages are returned in JSON without HTML encoding, then rendered by the Cloud Wizard frontend. An authenticated user can inject a malicious iframe that redirects the victim to an external site.

SQL injection vulnerability in pgAdmin 4 affects sixteen Jinja templates where user-supplied descriptions are directly interpolated into SQL literals without proper escaping. An authenticated user with permissions to create or alter objects (domains, foreign tables, languages, event triggers) can inject arbitrary SQL commands, potentially leading to OS command execution if the PostgreSQL role has superuser privileges.

In pgAdmin 4, MAX_LOGIN_ATTEMPTS is enforced only in the custom /authenticate/login view. Flask-Security's default /login view never consulted the User.locked field, allowing an attacker to bypass account lockout and perform unbounded online password guessing against INTERNAL accounts.

There is a path traversal vulnerability using symbolic links in pgAdmin 4 File Manager. An authenticated user can create a symbolic link in their directory pointing outside of it, allowing data to be written to any path accessible by the pgAdmin process.

In pgAdmin 4 FileBackedSessionManager, there is a vulnerability to deserialization of untrusted data, which can lead to remote code execution at the operating system level. This issue arises from the lack of proper integrity checks before deserializing session file contents.

Local file inclusion (LFI) and server-side request forgery (SSRF) vulnerabilities in pgAdmin 4 LLM API configuration endpoints. An authenticated user could read arbitrary server-side files via api_key_file or coerce pgAdmin into making requests to internal targets via api_url.

In pgAdmin 4 before version 9.15, there is an OS command injection vulnerability (CWE-78) in the Import/Export query export feature. An authenticated user could inject malicious commands, leading to arbitrary command execution on the pgAdmin server or arbitrary file writes.

A SQL injection vulnerability in the pgAdmin 4 Maintenance Tool allows an authenticated user with tools_maintenance permissions to execute arbitrary SQL commands on the PostgreSQL server. Exploiting this vulnerability could lead to privilege escalation and execution of operating system commands on the database host.

Stored cross-site scripting (XSS) vulnerability in pgAdmin 4 Browser Tree and Explain Visualizer modules. User-controlled PostgreSQL object names were assigned to DOM elements via innerHTML, allowing crafted object names containing HTML markup to execute attacker-supplied JavaScript in the browser of any pgAdmin user who navigated to or executed EXPLAIN over the malicious object.

pgAdmin <= 9.9 is affected by a vulnerability in the LDAP authentication mechanism allows bypassing TLS certificate verification.

pgAdmin <= 9.9 is affected by an LDAP injection vulnerability in the LDAP authentication flow. An attacker can inject special LDAP characters in the username, causing the DC/LDAP server and the client to process an unusual amount of data, leading to a DoS attack.

pgAdmin 4 versions up to 9.9 are affected by a command injection vulnerability on Windows systems. This issue is caused by the use of shell=True during backup and restore operations, enabling attackers to execute arbitrary system commands by providing specially crafted file path input.