Fernando Bortotti

**Name of the Vulnerable Software and Affected Versions** pgAdmin 4 versions 6.6 through 9.15 **Description** HTML injection is possible in the cloud deployment module. The application propagates exception text from AWS, Azure, and Google SDKs, as well as file-resolution and database-commit exceptions, into JSON response bodies within the `info` and `errormsg` fields without HTML-encoding. The Cloud Wizard frontend renders these strings using `html-react-parser`, allowing structural HTML to be embedded directly into the DOM. Technical details include the following affected endpoints: - '/rds/verify credentials/' - '/rds/deploy' - '/rds/regions' - '/rds/update-server' - '/azure/verify credentials' - '/azure/deploy' - '/azure/regions' - '/azure/update-server' - '/azure/check cluster name availability' - '/google/verify credentials' - '/google/deploy' - '/google/regions' - '/google/update-server' - '/google/verification ack' - '/google/projects' - '/google/instance types' - '/google/database versions' - '/cloud/deploy' - '/cloud/update cloud server' An attacker can use the `access key` variable to submit a crafted payload. For example, providing a value containing an iframe can lead to the browser fetching content from an attacker-controlled host and redirecting the victim's tab. This injection occurs within the pgAdmin interface, bypassing X-Frame-Options and Content-Security-Policy frame-ancestors. **Recommendations** Update pgAdmin 4 to version 9.16.

**Name of the Vulnerable Software and Affected Versions** pgAdmin 4 versions 6.9 through 9.15 **Description** In server mode, two state-mutating endpoints in the SQL Editor blueprint are missing the `@pga login required` authentication decorator, allowing them to be accessed without an authenticated session. These endpoints are 'DELETE /sqleditor/close/<trans id>' and 'POST /sqleditor/initialize/sqleditor/update connection/<sgid>/<sid>/<did>'. Both endpoints lead to a `pickle.loads` sink—the close endpoint via the `close sqleditor session()` function and the update connection endpoint via the `check transaction status()` function—which processes the `session['gridData'][<trans id>]['command obj']` variable. This creates a deserialization of untrusted data path. Remote code execution is possible if an attacker can forge a server-side session file containing a malicious pickle payload, which requires knowledge of the Flask `SECRET KEY` and write access to the `sessions/` directory on the host. If these conditions are met, the lack of authentication allows for arbitrary code execution under the account running the pgAdmin process, potentially leading to complete host compromise and database credential theft. **Recommendations** Update pgAdmin 4 to version 9.16.

**Name of the Vulnerable Software and Affected Versions** pgAdmin 4 versions 6.0 through 9.15 **Description** Stored cross-site scripting exists in the error-rendering and plan-node-rendering paths. Text returned by a PostgreSQL server, such as `ErrorResponse` messages, object names in relation-does-not-exist errors, and `EXPLAIN` Recheck Cond or Exact Heap Blocks fields, is passed verbatim through `html-react-parser` at various user-facing sinks. These sinks include notifier toasts, `FormFooterMessage`, `FormInput` help and error areas, `FormNote`, `ModalProvider` AlertContent and confirmDelete, `ToolErrorView`, the Explain visualiser's `NodeText` panel, SQL editor confirm dialogs, `ConfirmSaveContent`, `PreferencesHelper` modal alerts, and `SelectThemes` helper text. An attacker controlling a PostgreSQL server, or a low-privilege user capable of creating objects with crafted names, can inject arbitrary HTML, such as `<iframe>` tags, into the DOM. This occurs when a victim connects to the server or views an Explain plan referencing the crafted object. The injected iframe can execute JavaScript to redirect the user to an attacker-controlled URL. Because the injection occurs within the internal interface, standard anti-clickjacking controls like X-Frame-Options and Content-Security-Policy frame-ancestors are ineffective. **Recommendations** Update pgAdmin 4 to version 9.16 or later.

**Name of the Vulnerable Software and Affected Versions** pgAdmin 4 versions prior to 9.15 **Description** Improper restriction of excessive authentication attempts occurs because the `MAX LOGIN ATTEMPTS` setting is only enforced within the custom '/authenticate/login' endpoint. The default '/login' endpoint provided by Flask-Security does not check the `User.locked` field, relying instead on `UserMixin.is locked()` and `is active`, which do not properly validate the locked status. This allows an attacker to bypass brute-force protection for accounts using the INTERNAL authentication source by submitting credentials directly to the '/login' endpoint, enabling unbounded online password-guessing attacks. This issue does not affect users authenticated via LDAP, OAuth2, Kerberos, or Webserver as they lack local passwords. **Recommendations** Update pgAdmin 4 to version 9.15 or later.

**Name of the Vulnerable Software and Affected Versions** pgAdmin 4 versions prior to 9.15 **Description** The `FileBackedSessionManager` in pgAdmin 4 performs unsafe deserialization of session-file contents using Python's standard object-serialization module before conducting an HMAC integrity check. This allows any file placed in the sessions directory to be deserialized unconditionally. An authenticated user with write access to the sessions directory, potentially through misconfiguration or a path-traversal flaw, can use a crafted serialized payload to achieve operating-system level remote code execution under the pgAdmin process identity. **Recommendations** Update to version 9.15 or later. Restrict write access to the sessions directory to prevent unauthorized users from planting crafted files.

**Name of the Vulnerable Software and Affected Versions** pgAdmin 4 versions prior to 9.15 **Description** A symbolic-link path traversal issue exists in the pgAdmin 4 File Manager. The `check access permission()` function utilized `os.path.abspath`, which resolves parent directory references but fails to resolve symbolic links. Because the subsequent kernel write operation follows symbolic links, an authenticated user can create a symbolic link within their own storage directory that points to an external location. This allows the user to induce pgAdmin to write to any path accessible by the pgAdmin process, potentially compromising the integrity and availability of protected information. This is a TOCTOU (Time-of-Check to Time-of-Use) race condition between the access check and the file open operation. **Recommendations** Update to version 9.15 or later.