---
id: "CVE-2026-116250"
kind: "vulnerability"
aliases: ["CVE-2026-116250"]
title: "pgAdmin 4: symlink race lets server-mode file access escape storage directory"
severity: "high"
cvss: 7.3
epss: null
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["package", "pgadmin4", "postgresql", "server-mode"]
not_affected_if: ["desktop-mode", "pgadmin-before-9.19-not-used", "private-storage"]
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:34+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-116250", "first_seen_at": "2026-10-30T20:25:37+00:00"}]
---

# pgAdmin 4: symlink race lets server-mode file access escape storage directory

In server mode, pgAdmin 4 checks a user-supplied file path but then opens it by name, so a swapped-in symbolic or hard link can redirect reads and writes outside the storage directory. An attacker who can plant such links in the storage directory could read, overwrite or load files as the pgAdmin operating-system account.

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

## How to check

- Check the installed pgAdmin version with `pgadmin4 --version` or the package manager, and confirm whether it is older than `9.19`
- Confirm whether server mode is enabled in the pgAdmin configuration (`SERVER_MODE`)
- Check whether per-user storage directories sit on shared or network-mounted storage writable by other operating-system users

## Fix

- pgAdmin 4: upgrade to `9.19` or later

## Timeline

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

## From the sources

In server mode pgAdmin 4 validates a path a user gives for a file in their storage directory with check_access_permission() and then opened it by name. Several places opened it with a plain open() or handed the path to a utility that opened it later: the servers.json export and import and the import file listing, and the files given to pg_dump, pg_dumpall, pg_restore and psql by Backup, Restore and Import/Export Data. A symbolic link swapped in at the file or at any parent directory between the check and the open redirected the operation outside the storage directory, so a file could be written, overwritten or read, or loaded into a table, as the operating-system account running pgAdmin. A hard link to an outside file, which O_NOFOLLOW does not detect, and a FIFO, which could hang a request, had the same effect. CVE-2026-86861 fixed this for the File Manager's save_file; these were the remaining paths.

Exploitation requires creating such a link or FIFO inside the user's storage directory. pgAdmin offers no way to do so, and the per-user storage directories belong to the pgAdmin account, so this requires write access to the storage backend as a different operating-system user, for example a shared or network-mounted storage directory, and winning the race.

The fix opens each file by walking down from the storage directory one component at a time with O_NOFOLLOW, accepting only a regular file with one link, and passes the utilities the open descriptor (/dev/fd/N) on Linux. Error messages no longer include the server path.

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_