Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
28 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Authorization vulnerability in pgAdmin 4 server mode affecting Server Groups, Servers, Shared Servers, Background Processes, and Debugger modules. Multiple endpoints fetched user-owned objects without filtering by the requesting user's identity. An authenticated user could access another user's private servers, server groups, background processes, and debugger function arguments by guessing object IDs. Additionally, the Shared Servers feature contained multiple issues including credential leakage (passexeccmd, passfile, SSL keys), privilege escalation via writable passexeccmd (a shell command executed when establishing the connection) allowing arbitrary command execution in the owner's process context, and owner-data corruption via SQLAlchemy session mutations. Several owner-only fields (passexeccmd, passexecexpiration, dbres, dbrestype) were writable by non-owners through the API, and additional fields (kerberosconn, tags, postconnectionsql) lacked per-user persistence so non-owner…
Recommended action: Upgrade to 9.15 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Improper restriction of excessive authentication attempts (CWE-307) in pgAdmin 4. pgAdmin enforces MAXLOGINATTEMPTS only inside its custom /authenticate/login view. Flask-Security's default /login view, which is registered automatically by security.initapp() and is reachable on every server, never consulted the User.locked field: pgAdmin's User model relied on Flask-Security's UserMixin.islocked() (which always returns 'not locked') and Flask-Login's isactive (which only checks the active column, not locked). An attacker who triggered an account lockout via /authenticate/login could therefore obtain a session by re-submitting valid credentials directly to /login, defeating the brute-force-protection control for accounts using the INTERNAL authentication source. The same bypass also means that login attempts via /login are never rate-limited, so an attacker can perform an unbounded online password-guessing attack against INTERNAL accounts regardless of MAXLOGINATTEMPTS. Fix overrides…
Recommended action: Upgrade to 9.15 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Deserialization of untrusted data (CWE-502) in pgAdmin 4 FileBackedSessionManager. The session manager performed unsafe deserialization of session-file contents (using Python's standard object-serialization module) before performing any HMAC integrity check. Any file dropped into the sessions directory was deserialized unconditionally. An authenticated user with write access to the sessions directory (whether by misconfiguration or in combination with another path-traversal flaw) could plant a crafted serialized payload to achieve operating-system level remote code execution under the pgAdmin process identity. Fix prepends a 64-byte hex SHA-256 HMAC over the session body, computed with SECRETKEY, and verifies it via hmac.comparedigest before any deserialization. The check is raised (rather than asserted) on empty SECRETKEY so it is not stripped under -O. This issue affects pgAdmin 4: before 9.15.
Recommended action: Upgrade to 9.15 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Stored cross-site scripting (XSS) vulnerability in pgAdmin 4 Browser Tree and Explain Visualizer modules. User-controlled PostgreSQL object names (database, schema, table, column, etc.) 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. Fix replaces innerHTML with textContent. This issue affects pgAdmin 4: before 9.15.
Recommended action: Upgrade to 9.15 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
SQL injection vulnerability in pgAdmin 4 Maintenance Tool. Four user-supplied JSON fields (bufferusagelimit, vacuumparallel, vacuumindexcleanup, reindextablespace) were concatenated directly into the rendered VACUUM/ANALYZE/REINDEX command and passed to psql --command. An authenticated user with the toolsmaintenance permission could break out of the option syntax and execute arbitrary SQL on the connected PostgreSQL server. The injected SQL could in turn invoke COPY ... TO PROGRAM to escalate to operating-system command execution on the database host. Fix introduces server-side allow-listing of all four fields and switches reindextablespace from manual quoting to the qtIdent filter. This issue affects pgAdmin 4: before 9.15.
Recommended action: Upgrade to 9.15 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Local file inclusion (LFI) and server-side request forgery (SSRF) vulnerabilities in pgAdmin 4 LLM API configuration endpoints. User-supplied apikeyfile and apiurl preferences were passed to the LLM provider clients without validation. An authenticated user could read arbitrary server-side files by pointing apikeyfile at any path readable by the pgAdmin process, or coerce pgAdmin into making requests to internal targets (e.g. cloud metadata services such as 169.254.169.254) by setting apiurl, exploiting the chat path and model-list endpoints. Fix restricts apikeyfile to the user's private storage (server mode) or home directory (desktop mode), enforces a printable-ASCII key shape and a 1024-byte read cap, and gates apiurl against a configurable allow-list (config.ALLOWEDLLMAPIURLS) at every entry point. This issue affects pgAdmin 4: before 9.15.
Recommended action: Upgrade to 9.15 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Symbolic-link path traversal (CWE-61, CWE-22) in pgAdmin 4 File Manager. checkaccesspermission used os.path.abspath, which resolves '..' but does not resolve symbolic links, while the subsequent kernel write follows symlinks. An authenticated user could plant a symbolic link inside their own storage directory pointing outside it and induce pgAdmin to write to any path reachable by the pgAdmin process. Fix switches the access check to os.path.realpath for both source and destination, and adds an openuploadtarget helper that opens the target with ONOFOLLOW (mode 0o600) to close the leaf-component TOCTOU between the access check and the open. File mode is hardened from 0o644 to 0o600. This issue affects pgAdmin 4: before 9.15.
Recommended action: Upgrade to 9.15 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OS command injection (CWE-78) vulnerability in pgAdmin 4 Import/Export query export. User-supplied input was interpolated directly into a psql \copy metacommand template without sanitization. An authenticated user could inject ") TO PROGRAM 'cmd'" to break out of the \copy (...) context and achieve arbitrary command execution on the pgAdmin server, or ") TO '/path'" for arbitrary file write. Additional fields (format, onerror, logverbosity) were also raw-interpolated and exploitable. Fix adds a parens-balance parser modeled on psql's strtokx tokenizer, allow-lists format/onerror/logverbosity, rejects null bytes in the query, and tightens type and gating checks. This issue affects pgAdmin 4: before 9.15.
Recommended action: Upgrade to 9.15 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
pgAdmin versions 9.11 are affected by a Restore restriction bypass via key disclosure vulnerability that occurs when running in server mode and performing restores from PLAIN-format dump files. An attacker with access to the pgAdmin web interface can observe an active restore operation, extract the \restrict key in real time, and race the restore process by overwriting the restore script with a payload that re-enables meta-commands using \unrestrict <key. This results in reliable command execution on the pgAdmin host during the restore operation.
Recommended action: Upgrade to 9.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The PLAIN restore meta-command filter introduced in pgAdmin as part of the fix for CVE-2025-12762 does not detect meta-commands when a SQL file begins with a UTF-8 Byte Order Mark (EF BB BF) or other special byte sequences. The implemented filter uses the function hasmetacommands(), which scans raw bytes using a regular expression. The regex does not treat the bytes as ignorable, so meta-commands such as \\! remain undetected. When pgAdmin invokes psql with --file, psql strips the bytes and executes the command. This can result in remote command execution during a restore operation.
Recommended action: Upgrade to 9.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 9.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.
Recommended action: Upgrade to 9.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
pgAdmin <= 9.9 is affected by an LDAP injection vulnerability in the LDAP authentication flow that allows an attacker to inject special LDAP characters in the username, causing the DC/LDAP server and the client to process an unusual amount of data DOS.
Recommended action: Upgrade to 9.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
pgAdmin <= 9.9 is affected by a vulnerability in the LDAP authentication mechanism allows bypassing TLS certificate verification.
Recommended action: Upgrade to 9.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
pgAdmin <= 9.7 is affected by a Cross-Origin Opener Policy (COOP) vulnerability. This vulnerability allows an attacker to manipulate the OAuth flow, potentially leading to unauthorised account access, account takeover, data breaches, and privilege escalation.
Recommended action: Upgrade to 9.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Remote Code Execution security vulnerability in pgAdmin 4 (Query Tool and Cloud Deployment modules). The vulnerability is associated with the 2 POST endpoints; /sqleditor/querytool/download, where the querycommited parameter and /cloud/deploy endpoint, where the highavailability parameter is unsafely passed to the Python eval() function, allowing arbitrary code execution. This issue affects pgAdmin 4: before 9.2.
Recommended action: Upgrade to 9.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
pgAdmin <= 9.1 is affected by a security vulnerability with Cross-Site Scripting(XSS). If attackers execute any arbitrary HTML/JavaScript in a user's browser through query result rendering, then HTML/JavaScript runs on the browser.
Recommended action: Upgrade to 9.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability was found in pgadmin. Users logging into pgAdmin running in server mode using LDAP authentication may be attached to another user's session if multiple connection attempts occur simultaneously.
Recommended action: Upgrade to 7.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
pgAdmin versions 8.11 and earlier are vulnerable to a security flaw in OAuth2 authentication. This vulnerability allows an attacker to potentially obtain the client ID and secret, leading to unauthorized access to user data.
Recommended action: Upgrade to 8.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
pgAdmin <= 8.5 is affected by XSS vulnerability in /settings/store API response json payload. This vulnerability allows attackers to execute malicious script at the client end.
Recommended action: Upgrade to 8.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
pgAdmin <= 8.5 is affected by a multi-factor authentication bypass vulnerability. This vulnerability allows an attacker with knowledge of a legitimate account’s username and password may authenticate to the application and perform sensitive actions within the application, such as managing files and executing SQL queries, regardless of the account’s MFA enrollment status.
Recommended action: Upgrade to 8.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
pgAdmin <= 8.4 is affected by a Remote Code Execution (RCE) vulnerability through the validate binary path API. This vulnerability allows attackers to execute arbitrary code on the server hosting PGAdmin, posing a severe risk to the database management system's integrity and the security of the underlying data.
Recommended action: Upgrade to 8.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
pgAdmin prior to version 8.4 is affected by a path-traversal vulnerability while deserializing users’ sessions in the session handling code. If the server is running on Windows, an unauthenticated attacker can load and deserialize remote pickle objects and gain code execution. If the server is running on POSIX/Linux, an authenticated attacker can upload pickle objects, deserialize them and gain code execution.
Recommended action: Upgrade to 8.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A flaw was found in pgAdmin. This issue occurs when the pgAdmin server HTTP API validates the path a user selects to external PostgreSQL utilities such as pgdump and pgrestore. Versions of pgAdmin prior to 7.7 failed to properly control the server code executed on this API, allowing an authenticated user to run arbitrary commands on the server.
Recommended action: Upgrade to 7.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
pgAdmin 4 versions prior to v6.19 contains a directory traversal vulnerability. A user of the product may change another user's settings or alter the database.
Recommended action: Upgrade to 6.19 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.