---
id: "CVE-2026-116240"
kind: "vulnerability"
aliases: ["CVE-2026-116240"]
title: "pgAdmin 4: storage path checks let server-mode users read, write or delete files"
severity: "high"
cvss: 7.1
epss: null
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["linux", "package", "pgadmin", "postgresql", "self-hosted", "windows"]
not_affected_if: ["desktop-mode", "pgadmin-before-9.19-not-in-use"]
published_at: "2026-10-30T20:17:03+00:00"
first_seen_at: "2026-10-30T20:25:37+00:00"
updated_at: "2026-10-30T20:26:39+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-116240", "first_seen_at": "2026-10-30T20:25:37+00:00"}]
---

# pgAdmin 4: storage path checks let server-mode users read, write or delete files

In pgAdmin 4 server mode, several file-handling paths validate one path but act on a different one, so a user can reach files outside their storage directory. The sources say an attacker can read, write, list, delete or move files the pgAdmin account can reach, depending on platform and path shape.

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

## How to check

- Check the installed pgAdmin 4 version (`pgadmin4 --version` or the About dialog), and confirm it is in server mode.
- Confirm whether multiple users share one server-mode instance with storage directories whose names are prefixes of one another.

## 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-116240

## From the sources

In server mode pgAdmin 4 validates a path into the user's storage directory with check_access_permission(), which builds the absolute path with get_abs_path(). Several callers then acted on a path they built differently, so the path checked and the path used could name different files:

- Opening a file in the Query Tool, the Google client secret and, on Windows, Import/Export Data, Backup, Restore and saving a file joined the path to the storage directory after stripping leading slashes and backslashes. On POSIX a path checked as a name inside storage could become an absolute path once stripped, so any file the pgAdmin account can read could be opened; on Windows a path naming a drive discarded the storage directory, so these could read, or write, outside it.
- Listing a folder decoded the path a second time after the check, so a folder named like an encoded "..", which a user can create, listed any directory on the host.
- Download, delete, rename and the file-exists check appended the path to the storage directory without a separator, so in a deployment where one user's storage directory name is a prefix of another's, another user's files could be read, deleted or moved; download also checked the path appended to itself.
- Creating a folder could create one in another user's directory.

The fix makes check_access_permission() return the path it checked and every caller act on that path, decodes folder paths once, and opens, deletes and renames files relative to directories opened from the storage directory without following symbolic links. Desktop mode is not affected.

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_