Description
pgAdmin 4's File Manager save_file endpoint, which backs saving from the Query Tool and ERD, validated the requested path with Filemanager.check_access_permission() and then opened the file for writing with a plain open() call. CVE-2026-7819 had previously hardened the separate file upload path by opening its target with O_NOFOLLOW, so that the kernel refuses to follow a symbolic link at the final path component, but save_file was left on an unprotected open(). A symbolic link already present when the check ran was rejected by the check itself; the remaining exposure was a link substituted at the final path component in the interval between the check and the write, at which point the write followed the link and landed outside the user's storage directory, creating or overwriting an arbitrary file as the operating-system account running pgAdmin.

Exploitation requires the ability to create or replace a symbolic link inside the requesting user's storage directory. pgAdmin exposes no interface that creates symbolic links, so this requires filesystem access to the pgAdmin host or to a shared or network-mounted storage backend, together with winning the timing window. The reporter did not achieve a write against a released version, having attempted approximately 63,000 racing requests without success; the reported defect is the uncovered write path rather than a demonstrated sandbox escape.

The fix routes save_file's write through the same O_NOFOLLOW-protected helper already used by the upload path, so both File Manager write sinks carry identical kernel-enforced protection, and reports a symbolic-link refusal explicitly instead of surfacing the underlying system error text. Note that files created by save_file are now given mode 0600, inheriting the behaviour introduced for uploads. The protection covers the final path component; substitution of an intermediate directory component is not addressed by this change.

This issue affects pgAdmin 4: from the introduction of the containment check in the File Manager save path before 9.18.
Published: 2026-09-17
Score: 6 Medium
EPSS: < 1% Very Low
KEV: No
Impact: Arbitrary file write
Action: Patch
AI Analysis

Impact

pgAdmin 4's File Manager save_file endpoint allows an attacker to write an arbitrary file outside the allotted user storage directory by leveraging a race condition between a permissions check and an unprotected open() call. The vulnerability permits filesystem writes to any location reachable by the operating‑system account running pgAdmin, effectively giving local attackers the ability to overwrite or create arbitrary files. This weakness is consistent with CWE-367 (Race Condition) and CWE-59 (Symbolic Link Dereference).

Affected Systems

This defect affects all pgAdmin 4 installations up to and including version 9.17, as the containment check introduced before 9.18 did not guard the final path component with O_NOFOLLOW. The vulnerability is publicly documented for the pgadmin.org:pgAdmin 4 product line, but no specific patch version is listed in the provided data. Administrators should verify whether their installation is at or below 9.17.

Risk and Exploitability

The CVSS score of 6 indicates moderate severity, while the EPSS score is not available and the vulnerability is not listed in CISA's KEV catalog, suggesting limited evidence of exploitation. Successful exploitation requires filesystem write access or the ability to create or replace a symbolic link within the user’s storage directory, and precise timing to replace the link between the check and the write. Because the attack only succeeds when the attacker controls the filesystem or shares a network‑mounted backend, the likelihood of exploitation is low in tightly controlled environments but remains a concern in scenarios where users have local filesystem privileges.

Generated by OpenCVE AI on September 17, 2026 at 20:27 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Update pgAdmin 4 to the latest release (≥9.18) which protects the save file path with O_NOFOLLOW and refuses symbolic links.
  • If an upgrade is not immediately possible, configure the storage directory permissions to remove write or symlink creation rights for untrusted users, preventing the race condition from being exploitable.
  • Monitor the file system for unexpected writes or symbolic link creations within the user storage directories and audit logs for the save_file operation.

Generated by OpenCVE AI on September 17, 2026 at 20:27 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Mon, 21 Sep 2026 17:45:00 +0000

Type Values Removed Values Added
CPEs cpe:2.3:a:pgadmin:pgadmin_4:*:*:*:*:*:postgresql:*:*

Thu, 17 Sep 2026 20:45:00 +0000

Type Values Removed Values Added
First Time appeared Pgadmin
Pgadmin pgadmin 4
Vendors & Products Pgadmin
Pgadmin pgadmin 4

Thu, 17 Sep 2026 20:30:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}


Thu, 17 Sep 2026 15:45:00 +0000

Type Values Removed Values Added
Description pgAdmin 4's File Manager save_file endpoint, which backs saving from the Query Tool and ERD, validated the requested path with Filemanager.check_access_permission() and then opened the file for writing with a plain open() call. CVE-2026-7819 had previously hardened the separate file upload path by opening its target with O_NOFOLLOW, so that the kernel refuses to follow a symbolic link at the final path component, but save_file was left on an unprotected open(). A symbolic link already present when the check ran was rejected by the check itself; the remaining exposure was a link substituted at the final path component in the interval between the check and the write, at which point the write followed the link and landed outside the user's storage directory, creating or overwriting an arbitrary file as the operating-system account running pgAdmin. Exploitation requires the ability to create or replace a symbolic link inside the requesting user's storage directory. pgAdmin exposes no interface that creates symbolic links, so this requires filesystem access to the pgAdmin host or to a shared or network-mounted storage backend, together with winning the timing window. The reporter did not achieve a write against a released version, having attempted approximately 63,000 racing requests without success; the reported defect is the uncovered write path rather than a demonstrated sandbox escape. The fix routes save_file's write through the same O_NOFOLLOW-protected helper already used by the upload path, so both File Manager write sinks carry identical kernel-enforced protection, and reports a symbolic-link refusal explicitly instead of surfacing the underlying system error text. Note that files created by save_file are now given mode 0600, inheriting the behaviour introduced for uploads. The protection covers the final path component; substitution of an intermediate directory component is not addressed by this change. This issue affects pgAdmin 4: from the introduction of the containment check in the File Manager save path before 9.18.
Title pgAdmin 4: File Manager save_file writes through a symbolic link planted after the containment check
Weaknesses CWE-367
CWE-59
References
Metrics cvssV3_1

{'score': 5.9, 'vector': 'CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:L'}

cvssV4_0

{'score': 6, 'vector': 'CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N'}


Subscriptions

Pgadmin Pgadmin 4
cve-icon MITRE

Status: PUBLISHED

Assigner: PostgreSQL

Published:

Updated: 2026-09-17T19:18:18.115Z

Reserved: 2026-09-08T15:47:04.229Z

Link: CVE-2026-86861

cve-icon Vulnrichment

Updated: 2026-09-17T19:18:12.760Z

cve-icon NVD

Status : Analyzed

Published: 2026-09-17T16:18:17.533

Modified: 2026-09-21T17:26:49.647

Link: CVE-2026-86861

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-09-17T20:30:17Z

Weaknesses
  • CWE-367

    Time-of-check Time-of-use (TOCTOU) Race Condition

  • CWE-59

    Improper Link Resolution Before File Access ('Link Following')