Pgadmin Org
Monthly
Arbitrary file write and credential disclosure in pgAdmin 4 (versions before 9.18) let any authenticated user holding the tools_backup permission - which is granted to the default User role - run pg_dump with attacker-controlled arguments and connection parameters. Because the Backup tool appended the client-supplied 'database' field to the pg_dump argument vector unvalidated, a value starting with a dash is parsed by getopt_long as an option (for example --file=/absolute/path) and overrides the storage-confined output path, letting files be created or overwritten anywhere the pgAdmin OS account can write; a value containing an equals sign is expanded by libpq into a full connection string that overrides the intended host and port and redirects pg_dump to an attacker-nominated server while the decrypted stored database password is exported in PGPASSWORD. Exploitation requires valid credentials (PR:L, remote, no user interaction) and no public exploit code or confirmed active exploitation has been identified at time of analysis, but the impact is high severity and a fix is available in 9.18.
Authentication bypass in pgAdmin 4 (versions 6.2 through 9.17) lets any client that can reach the pgAdmin web interface assume an arbitrary identity - including an existing Administrator account - without supplying a password or any other credential, when the non-default 'webserver' authentication source is enabled. The flaw, a spoofing-based authentication bypass (CWE-290), arises because the WebserverAuthentication class fell back to reading config.WEBSERVER_REMOTE_USER directly from client-controlled inbound HTTP request headers when the WSGI/CGI environment lookup returned nothing, and because headers named with an HTTP_ prefix or hyphens (for example HTTP_X_FORWARDED_USER or X-Forwarded-User) are placed into the WSGI environment by the server itself, satisfying the 'trusted' environment path. Per the assessed CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H the attack is unauthenticated and requires no user interaction, so unpatched deployments in webserver-auth mode should be treated as fully compromised by any network-reachable client; no public exploit code has been identified at time of analysis and the issue is not confirmed as actively exploited (CISA KEV).
Credential disclosure in pgAdmin 4 before 9.18 allows an authenticated user holding the default User role to redirect the Restore and Maintenance tools' database connection to a host of the attacker's choosing, causing the decrypted stored database password exported in PGPASSWORD to be presented to that endpoint and captured. The root cause is an argument-injection flaw (CWE-88) in the handling of the client-supplied 'database' field, which pgAdmin passes as the value of --dbname to pg_restore and psql; libpq expands any value containing an equals sign into a full connection string whose keywords override the --host and --port arguments pgAdmin supplies. No public exploit code has been identified at time of analysis and there is no CISA KEV entry, but the vendor has released a fix in 9.18; the assessed impact is confidentiality-only (CVSS v3.1 7.1, PR:L, C:H/I:N/A:N), requiring only a low-privileged authenticated session and no victim interaction, with exposure contingent on the attacker-nominated endpoint being network-reachable from the pgAdmin host.
Stored cross-site scripting in pgAdmin 4 versions 6.0 through 9.15 allows a malicious or attacker-influenced PostgreSQL server to inject arbitrary HTML into pgAdmin's interface via ErrorResponse messages and EXPLAIN plan fields rendered through html-react-parser. Because the injection executes inside pgAdmin's own DOM, an attacker can render convincing phishing dialogs or redirect the top-level tab via iframe srcdoc, bypassing standard X-Frame-Options and frame-ancestors protections. No public exploit identified at time of analysis, but the vendor has shipped a multi-layer fix in 9.16.
Remote unauthenticated access to two SQL Editor endpoints in pgAdmin 4 server-mode deployments (versions 6.9 through 9.15) exposes a pickle.loads sink that can be reached without a valid pgAdmin session. The defect is the missing @pga_login_required decorator on DELETE /sqleditor/close/<trans_id> and POST /sqleditor/initialize/sqleditor/update_connection/<sgid>/<sid>/<did>; turning this into code execution additionally requires an attacker to possess the Flask SECRET_KEY and write access to the sessions/ directory from a separate channel. No public exploit identified at time of analysis, and the issue does not appear on CISA KEV.
Remote SQL injection via prompt injection in pgAdmin 4 versions 9.13 through 9.15 allows attackers who can write content into database objects the AI Assistant inspects to bypass the read-only transaction wrapper and execute arbitrary SQL with the pgAdmin user's database role. When that role is a PostgreSQL superuser or holds pg_execute_server_program, the chain escalates to remote code execution on the database host via COPY ... TO PROGRAM. No public exploit identified at time of analysis; CVSS 4.0 base score is 9.4 (Critical) and an upstream fix is available.
SQL injection in pgAdmin 4 versions 1.0 through 9.15 allows an authenticated user with object-modification rights to inject SQL via the description field of Domain, Domain Constraint, Foreign Table, Language, Event Trigger, and View dialogs, where Jinja templates wrapped the value in single quotes instead of passing it through the qtLiteral escape filter. Sixteen template sites plus ten related pgstattuple/pgstatindex identifier sinks share the defect; injected SQL executes as the connected PostgreSQL role, and if that role can use COPY ... TO/FROM PROGRAM it pivots to OS command execution on the database host. No public exploit identified at time of analysis, and the vendor notes the bug does not cross a privilege boundary since the same user already has direct SQL access via the Query Tool.
Symbolic link path traversal in pgAdmin 4 File Manager allows authenticated users to write arbitrary files on the server filesystem. Attackers with valid credentials can plant symlinks in their storage directory pointing outside it, bypassing access controls to overwrite critical system files or application configurations with pgAdmin process privileges. The vulnerability combines CWE-61 (symlink following) with a time-of-check-time-of-use race condition. Affects all pgAdmin 4 versions before 9.15. No active exploitation confirmed (not in CISA KEV), but exploit is straightforward for authenticated attackers given the detailed fix description published by PostgreSQL project.
Unsafe Python pickle deserialization in pgAdmin 4 FileBackedSessionManager allows authenticated local users with session-directory write access to execute arbitrary code as the pgAdmin process. The vulnerability arises from deserializing session files before validating their HMAC signature, enabling payload injection through crafted pickle objects. Attackers require both valid authentication and filesystem write permission to the sessions directory-achievable through misconfiguration or chaining with a separate path-traversal vulnerability. EPSS exploitation probability and KEV status not provided; no public exploit code identified at time of analysis. PostgreSQL maintainers confirmed the flaw and patched it in version 9.15 by implementing pre-deserialization HMAC validation.
Authenticated users in pgAdmin 4 before version 9.15 can read arbitrary server-side files or trigger server-side request forgery (SSRF) attacks via unvalidated LLM API configuration endpoints. The vulnerabilities exist in the chat and model-list endpoints where user-supplied api_key_file and api_url parameters are passed directly to LLM provider clients without sanitization, enabling attackers to exfiltrate sensitive files (database credentials, private keys) readable by the pgAdmin process or coerce internal requests to cloud metadata services and private infrastructure.
Authenticated remote code execution in pgAdmin 4 versions before 9.15 allows low-privilege users to execute arbitrary OS commands on the pgAdmin server via unsanitized input in the Import/Export query export feature. Attackers inject malicious payloads into psql \copy metacommand templates to break out of the query context and invoke PROGRAM directives or write arbitrary files. No public exploit code identified at time of analysis, but exploitation requires only low-privilege authenticated access with no user interaction (CVSS AV:N/AC:L/PR:L/UI:N). EPSS data not provided; KEV status not confirmed.
SQL injection in pgAdmin 4 Maintenance Tool allows authenticated users with tools_maintenance permission to execute arbitrary SQL and escalate to operating-system command execution on PostgreSQL database hosts. Four JSON fields (buffer_usage_limit, vacuum_parallel, vacuum_index_cleanup, reindex_tablespace) are concatenated unsafely into VACUUM/ANALYZE/REINDEX commands passed to psql. Attackers can break out of option syntax, inject SQL statements, and leverage PostgreSQL's COPY ... TO PROGRAM to achieve OS-level code execution. Fixed in version 9.15 via server-side allow-listing and proper input sanitization using qtIdent filter. EPSS data not available; no public exploit identified at time of analysis.
Authorization bypass and privilege escalation in pgAdmin 4 server mode allows authenticated users to access other users' private database servers, credentials, and background processes by guessing object IDs. Attackers can execute arbitrary shell commands as the server owner by modifying the passexec_cmd field through unprotected API endpoints. The vulnerability combines horizontal privilege escalation (accessing peer users' objects), vertical escalation (executing commands as owner), and credential theft (SSL keys, passfiles). No public exploit code identified at time of analysis, but exploitation requires only low-privilege authentication with no user interaction (CVSS PR:L/UI:N). EPSS data not provided; CISA KEV status not confirmed.
A time-of-check/time-of-use race in the pgAdmin 4 File Manager save_file endpoint (versions before 9.18) allows an authenticated user who can also plant or replace a symbolic link inside their own storage directory to redirect a save issued from the Query Tool or ERD so the write follows the link and lands outside the intended storage path, creating or overwriting an arbitrary file as the operating-system account running pgAdmin. Exploitation is tightly constrained: pgAdmin exposes no symlink-creation interface, so the attacker needs filesystem access to the pgAdmin host or a shared/network-mounted storage backend, plus a winning timing window that the reporter could not achieve in roughly 63,000 racing requests against a released build, and no public exploit code or confirmed active exploitation is known. The reported defect is a genuine but low-priority uncovered write path rather than a demonstrated sandbox escape.
Open redirect in pgAdmin 4's MFA validate and register endpoints allows network-accessible attackers to abuse the authentication flow as a phishing launchpad. Affected versions 6.0 through 9.15 pass the user-supplied 'next' query and form parameter directly to Flask's redirect response without verifying the target is same-origin, meaning a crafted URL such as /mfa/validate?next=https://attacker.example/fake-login silently forwards the victim from a trusted pgAdmin URL to an attacker-controlled site. No public exploit is identified at time of analysis and this CVE is not listed in CISA KEV; however, a reporter-supplied PoC was confirmed by the vendor and is documented in the upstream regression test suite.
HTML injection in pgAdmin 4's Cloud Wizard (versions 6.6 through 9.15.x) allows authenticated users to embed arbitrary HTML into the tool's DOM by exploiting unescaped AWS, Azure, and Google Cloud SDK exception text propagated into JSON response fields and parsed by html-react-parser. The primary impact is self-targeted DOM manipulation - the authenticated user who submits the crafted payload is the one who sees it rendered - with escalation to cross-user exploitation requiring an additional CSRF primitive to forge a valid X-pgA-CSRFToken in a victim's browser. No public exploit code has been identified and the vulnerability is not listed in CISA KEV, consistent with its CVSS 4.0 Medium rating of 4.8.
Low-severity SQL injection in pgAdmin 4's named restore point endpoint (POST /browser/server/restore_point/{gid}/{sid}) allows authenticated users to inject arbitrary SQL statements, but only within the privileges of their existing database role. The vulnerability is patched in pgAdmin 4 9.16, with no evidence of active exploitation (EPSS 0.21%, no KEV) and low real-world risk due to the absence of privilege escalation.
pgAdmin 4 before version 9.15 allows unauthenticated attackers to bypass account lockout and perform unbounded password-guessing attacks against INTERNAL authentication accounts by exploiting Flask-Security's default /login endpoint, which does not enforce the locked column that the custom /authenticate/login view relies on for brute-force protection. The vulnerability affects only accounts using pgAdmin's INTERNAL authentication source; LDAP, OAuth2, Kerberos, and Webserver authentication methods are not vulnerable because they do not use local passwords.
Stored cross-site scripting (XSS) in pgAdmin 4 before version 9.15 allows authenticated administrators to execute arbitrary JavaScript in the browsers of other pgAdmin users by crafting malicious PostgreSQL object names (databases, schemas, tables, columns) that are rendered unsafely via innerHTML in the Browser Tree and Explain Visualizer modules. The vulnerability requires administrator privileges and user interaction (navigation to or EXPLAIN execution over the malicious object), limiting real-world exploitation scope despite the network attack vector.
Arbitrary file write and credential disclosure in pgAdmin 4 (versions before 9.18) let any authenticated user holding the tools_backup permission - which is granted to the default User role - run pg_dump with attacker-controlled arguments and connection parameters. Because the Backup tool appended the client-supplied 'database' field to the pg_dump argument vector unvalidated, a value starting with a dash is parsed by getopt_long as an option (for example --file=/absolute/path) and overrides the storage-confined output path, letting files be created or overwritten anywhere the pgAdmin OS account can write; a value containing an equals sign is expanded by libpq into a full connection string that overrides the intended host and port and redirects pg_dump to an attacker-nominated server while the decrypted stored database password is exported in PGPASSWORD. Exploitation requires valid credentials (PR:L, remote, no user interaction) and no public exploit code or confirmed active exploitation has been identified at time of analysis, but the impact is high severity and a fix is available in 9.18.
Authentication bypass in pgAdmin 4 (versions 6.2 through 9.17) lets any client that can reach the pgAdmin web interface assume an arbitrary identity - including an existing Administrator account - without supplying a password or any other credential, when the non-default 'webserver' authentication source is enabled. The flaw, a spoofing-based authentication bypass (CWE-290), arises because the WebserverAuthentication class fell back to reading config.WEBSERVER_REMOTE_USER directly from client-controlled inbound HTTP request headers when the WSGI/CGI environment lookup returned nothing, and because headers named with an HTTP_ prefix or hyphens (for example HTTP_X_FORWARDED_USER or X-Forwarded-User) are placed into the WSGI environment by the server itself, satisfying the 'trusted' environment path. Per the assessed CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H the attack is unauthenticated and requires no user interaction, so unpatched deployments in webserver-auth mode should be treated as fully compromised by any network-reachable client; no public exploit code has been identified at time of analysis and the issue is not confirmed as actively exploited (CISA KEV).
Credential disclosure in pgAdmin 4 before 9.18 allows an authenticated user holding the default User role to redirect the Restore and Maintenance tools' database connection to a host of the attacker's choosing, causing the decrypted stored database password exported in PGPASSWORD to be presented to that endpoint and captured. The root cause is an argument-injection flaw (CWE-88) in the handling of the client-supplied 'database' field, which pgAdmin passes as the value of --dbname to pg_restore and psql; libpq expands any value containing an equals sign into a full connection string whose keywords override the --host and --port arguments pgAdmin supplies. No public exploit code has been identified at time of analysis and there is no CISA KEV entry, but the vendor has released a fix in 9.18; the assessed impact is confidentiality-only (CVSS v3.1 7.1, PR:L, C:H/I:N/A:N), requiring only a low-privileged authenticated session and no victim interaction, with exposure contingent on the attacker-nominated endpoint being network-reachable from the pgAdmin host.
Stored cross-site scripting in pgAdmin 4 versions 6.0 through 9.15 allows a malicious or attacker-influenced PostgreSQL server to inject arbitrary HTML into pgAdmin's interface via ErrorResponse messages and EXPLAIN plan fields rendered through html-react-parser. Because the injection executes inside pgAdmin's own DOM, an attacker can render convincing phishing dialogs or redirect the top-level tab via iframe srcdoc, bypassing standard X-Frame-Options and frame-ancestors protections. No public exploit identified at time of analysis, but the vendor has shipped a multi-layer fix in 9.16.
Remote unauthenticated access to two SQL Editor endpoints in pgAdmin 4 server-mode deployments (versions 6.9 through 9.15) exposes a pickle.loads sink that can be reached without a valid pgAdmin session. The defect is the missing @pga_login_required decorator on DELETE /sqleditor/close/<trans_id> and POST /sqleditor/initialize/sqleditor/update_connection/<sgid>/<sid>/<did>; turning this into code execution additionally requires an attacker to possess the Flask SECRET_KEY and write access to the sessions/ directory from a separate channel. No public exploit identified at time of analysis, and the issue does not appear on CISA KEV.
Remote SQL injection via prompt injection in pgAdmin 4 versions 9.13 through 9.15 allows attackers who can write content into database objects the AI Assistant inspects to bypass the read-only transaction wrapper and execute arbitrary SQL with the pgAdmin user's database role. When that role is a PostgreSQL superuser or holds pg_execute_server_program, the chain escalates to remote code execution on the database host via COPY ... TO PROGRAM. No public exploit identified at time of analysis; CVSS 4.0 base score is 9.4 (Critical) and an upstream fix is available.
SQL injection in pgAdmin 4 versions 1.0 through 9.15 allows an authenticated user with object-modification rights to inject SQL via the description field of Domain, Domain Constraint, Foreign Table, Language, Event Trigger, and View dialogs, where Jinja templates wrapped the value in single quotes instead of passing it through the qtLiteral escape filter. Sixteen template sites plus ten related pgstattuple/pgstatindex identifier sinks share the defect; injected SQL executes as the connected PostgreSQL role, and if that role can use COPY ... TO/FROM PROGRAM it pivots to OS command execution on the database host. No public exploit identified at time of analysis, and the vendor notes the bug does not cross a privilege boundary since the same user already has direct SQL access via the Query Tool.
Symbolic link path traversal in pgAdmin 4 File Manager allows authenticated users to write arbitrary files on the server filesystem. Attackers with valid credentials can plant symlinks in their storage directory pointing outside it, bypassing access controls to overwrite critical system files or application configurations with pgAdmin process privileges. The vulnerability combines CWE-61 (symlink following) with a time-of-check-time-of-use race condition. Affects all pgAdmin 4 versions before 9.15. No active exploitation confirmed (not in CISA KEV), but exploit is straightforward for authenticated attackers given the detailed fix description published by PostgreSQL project.
Unsafe Python pickle deserialization in pgAdmin 4 FileBackedSessionManager allows authenticated local users with session-directory write access to execute arbitrary code as the pgAdmin process. The vulnerability arises from deserializing session files before validating their HMAC signature, enabling payload injection through crafted pickle objects. Attackers require both valid authentication and filesystem write permission to the sessions directory-achievable through misconfiguration or chaining with a separate path-traversal vulnerability. EPSS exploitation probability and KEV status not provided; no public exploit code identified at time of analysis. PostgreSQL maintainers confirmed the flaw and patched it in version 9.15 by implementing pre-deserialization HMAC validation.
Authenticated users in pgAdmin 4 before version 9.15 can read arbitrary server-side files or trigger server-side request forgery (SSRF) attacks via unvalidated LLM API configuration endpoints. The vulnerabilities exist in the chat and model-list endpoints where user-supplied api_key_file and api_url parameters are passed directly to LLM provider clients without sanitization, enabling attackers to exfiltrate sensitive files (database credentials, private keys) readable by the pgAdmin process or coerce internal requests to cloud metadata services and private infrastructure.
Authenticated remote code execution in pgAdmin 4 versions before 9.15 allows low-privilege users to execute arbitrary OS commands on the pgAdmin server via unsanitized input in the Import/Export query export feature. Attackers inject malicious payloads into psql \copy metacommand templates to break out of the query context and invoke PROGRAM directives or write arbitrary files. No public exploit code identified at time of analysis, but exploitation requires only low-privilege authenticated access with no user interaction (CVSS AV:N/AC:L/PR:L/UI:N). EPSS data not provided; KEV status not confirmed.
SQL injection in pgAdmin 4 Maintenance Tool allows authenticated users with tools_maintenance permission to execute arbitrary SQL and escalate to operating-system command execution on PostgreSQL database hosts. Four JSON fields (buffer_usage_limit, vacuum_parallel, vacuum_index_cleanup, reindex_tablespace) are concatenated unsafely into VACUUM/ANALYZE/REINDEX commands passed to psql. Attackers can break out of option syntax, inject SQL statements, and leverage PostgreSQL's COPY ... TO PROGRAM to achieve OS-level code execution. Fixed in version 9.15 via server-side allow-listing and proper input sanitization using qtIdent filter. EPSS data not available; no public exploit identified at time of analysis.
Authorization bypass and privilege escalation in pgAdmin 4 server mode allows authenticated users to access other users' private database servers, credentials, and background processes by guessing object IDs. Attackers can execute arbitrary shell commands as the server owner by modifying the passexec_cmd field through unprotected API endpoints. The vulnerability combines horizontal privilege escalation (accessing peer users' objects), vertical escalation (executing commands as owner), and credential theft (SSL keys, passfiles). No public exploit code identified at time of analysis, but exploitation requires only low-privilege authentication with no user interaction (CVSS PR:L/UI:N). EPSS data not provided; CISA KEV status not confirmed.
A time-of-check/time-of-use race in the pgAdmin 4 File Manager save_file endpoint (versions before 9.18) allows an authenticated user who can also plant or replace a symbolic link inside their own storage directory to redirect a save issued from the Query Tool or ERD so the write follows the link and lands outside the intended storage path, creating or overwriting an arbitrary file as the operating-system account running pgAdmin. Exploitation is tightly constrained: pgAdmin exposes no symlink-creation interface, so the attacker needs filesystem access to the pgAdmin host or a shared/network-mounted storage backend, plus a winning timing window that the reporter could not achieve in roughly 63,000 racing requests against a released build, and no public exploit code or confirmed active exploitation is known. The reported defect is a genuine but low-priority uncovered write path rather than a demonstrated sandbox escape.
Open redirect in pgAdmin 4's MFA validate and register endpoints allows network-accessible attackers to abuse the authentication flow as a phishing launchpad. Affected versions 6.0 through 9.15 pass the user-supplied 'next' query and form parameter directly to Flask's redirect response without verifying the target is same-origin, meaning a crafted URL such as /mfa/validate?next=https://attacker.example/fake-login silently forwards the victim from a trusted pgAdmin URL to an attacker-controlled site. No public exploit is identified at time of analysis and this CVE is not listed in CISA KEV; however, a reporter-supplied PoC was confirmed by the vendor and is documented in the upstream regression test suite.
HTML injection in pgAdmin 4's Cloud Wizard (versions 6.6 through 9.15.x) allows authenticated users to embed arbitrary HTML into the tool's DOM by exploiting unescaped AWS, Azure, and Google Cloud SDK exception text propagated into JSON response fields and parsed by html-react-parser. The primary impact is self-targeted DOM manipulation - the authenticated user who submits the crafted payload is the one who sees it rendered - with escalation to cross-user exploitation requiring an additional CSRF primitive to forge a valid X-pgA-CSRFToken in a victim's browser. No public exploit code has been identified and the vulnerability is not listed in CISA KEV, consistent with its CVSS 4.0 Medium rating of 4.8.
Low-severity SQL injection in pgAdmin 4's named restore point endpoint (POST /browser/server/restore_point/{gid}/{sid}) allows authenticated users to inject arbitrary SQL statements, but only within the privileges of their existing database role. The vulnerability is patched in pgAdmin 4 9.16, with no evidence of active exploitation (EPSS 0.21%, no KEV) and low real-world risk due to the absence of privilege escalation.
pgAdmin 4 before version 9.15 allows unauthenticated attackers to bypass account lockout and perform unbounded password-guessing attacks against INTERNAL authentication accounts by exploiting Flask-Security's default /login endpoint, which does not enforce the locked column that the custom /authenticate/login view relies on for brute-force protection. The vulnerability affects only accounts using pgAdmin's INTERNAL authentication source; LDAP, OAuth2, Kerberos, and Webserver authentication methods are not vulnerable because they do not use local passwords.
Stored cross-site scripting (XSS) in pgAdmin 4 before version 9.15 allows authenticated administrators to execute arbitrary JavaScript in the browsers of other pgAdmin users by crafting malicious PostgreSQL object names (databases, schemas, tables, columns) that are rendered unsafely via innerHTML in the Browser Tree and Explain Visualizer modules. The vulnerability requires administrator privileges and user interaction (navigation to or EXPLAIN execution over the malicious object), limiting real-world exploitation scope despite the network attack vector.