---
id: "CVE-2026-116249"
kind: "vulnerability"
aliases: ["CVE-2026-116249"]
title: "pgAdmin 4: server mode reads other users' credential files via path traversal"
severity: "high"
cvss: 8.4
epss: null
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["package", "pgadmin", "postgresql", "server-mode"]
not_affected_if: ["desktop-mode", "single-user"]
published_at: "2026-10-30T20:17:05+00:00"
first_seen_at: "2026-10-30T20:25:37+00:00"
updated_at: "2026-10-30T20:26:20+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-116249", "first_seen_at": "2026-10-30T20:25:37+00:00"}]
---

# pgAdmin 4: server mode reads other users' credential files via path traversal

In pgAdmin 4 server mode, a crafted password file, certificate, key or SSH identity path (such as one with ../) makes the server read another user's saved passwords, client certificate or SSH key. A crafted sslkeylogfile path can also make libpq create or append files as the account running pgAdmin.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check the pgAdmin 4 version in use; affected releases are before `9.19`.
- Review saved server definitions and servers.json imports for file paths containing `..`.

## Fix

- pgAdmin 4 `9.19` or later (per the description, the fix is in releases from `9.19` onward)

## Timeline

- 2026-10-30T20:25:37+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-116249

## From the sources

In server mode pgAdmin 4 resolves a server's password file, SSL certificate, key, CRL and SSH tunnel identity file relative to the user's storage directory, but get_complete_file_path() only stripped leading slashes before joining the two. A path such as "../<another user>/.pgpass", set through the server dialog, the REST API or a servers.json import, therefore named another user's file, and connecting used that user's saved passwords, client certificate or SSH key. The sslkeylogfile connection parameter was passed to libpq unchanged, so a path outside storage let libpq create or append a file as the account running pgAdmin.

make_conninfo() also quoted connection parameter values but not their names, so a crafted parameter name could smuggle additional keyword=value pairs past these checks.

The fix requires the resolved path, with symbolic links followed, to stay inside the user's storage directory or the named shared storage directory, confines sslkeylogfile the same way, and accepts only exact libpq keywords as connection parameter names. A refused path or keyword is reported instead of letting libpq fall back to a default.

This issue affects pgAdmin 4: before 9.19.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_