CVE Vulnerability Catalog

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.

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 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 Secret Server on-prem versions earlier than 12.3.1, a user under certain conditions could submit an unsigned JWT and receive cloudadmin permissions in response. This enables privilege escalation to administrative level.

In Secret Server on-prem versions earlier than 12.3.1, a user could cause a two-factor PIN code to be generated for any account without prior authentication, then bypass the initial login step and authenticate using the second factor alone.

In Secret Server on-prem versions earlier than 12.3.1, the application did not always validate the PIN or biometric check when using a FIDO2-compliant device. This may allow bypassing the additional authentication factor.

The All In One Login WordPress plugin in versions up to 2.4.1 contains an unauthenticated Cross Site Scripting (XSS) vulnerability.

The LeadSnap WordPress plugin in versions up to 1.25 contains an unauthenticated PHP Object Injection vulnerability.

WIT SynApps Runtime through 1.4.11 contains a browser-mediated cross-origin request forgery vulnerability that allows attackers to supply an arbitrary target address during controller onboarding, causing the victim's browser to issue discovery requests to attacker-specified hosts. Attackers can leverage the victim's browser reachability to probe loopback addresses, local hostnames, or internal-only network hosts and initiate enrollment against REDY instances, crossing IT/OT segmentation boundaries.

WIT SynApps Runtime through 1.4.11 contains a pre-authentication reflected cross-site scripting vulnerability that allows unauthenticated attackers to inject and execute arbitrary JavaScript by submitting a crafted LINK query parameter to the /System/Session-1 endpoint. Attackers can exploit this flaw to harvest credentials, manipulate the login flow, access browser-visible data, and perform same-origin requests to controller endpoints.

WIT SynApps Runtime through 1.4.11 contains a hardcoded credentials vulnerability. Static OAuth clientId and clientSecret values are embedded in JavaScript delivered to the frontend, such as in parameters.js, allowing unauthenticated attackers to recover them.

The GS Testimonial Slider WordPress plugin in versions up to 3.3.10 contains a contributor-level PHP Object Injection vulnerability.

An incorrect authorization vulnerability exists in the single-stage query engine of Apache Pinot. When broker access control is enabled, the engine authorizes only the table named in the query's FROM clause, ignoring the dimension table identified by the `lookup()` transform function. An authenticated user authorized for at least one table can read columns from any dimension table in the cluster, including tables they have no access to, and retrieve arbitrary rows by supplying primary key values. Per-principal row-level security filters are also not applied. This affects Apache Pinot through 1.5.1 and is fixed in 1.6.0.