CVE-2026-86861: pgAdmin 4: File Manager save_file writes through a symbolic link planted after the containment check
pgAdmin 4's File Manager savefile endpoint, which backs saving from the Query Tool and ERD, validated the requested path with Filemanager.checkaccesspermission() 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 ONOFOLLOW, so that the kernel refuses to follow a symbolic link at the final path component, but savefile 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 savefile's write through the same ONOFOLLOW-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 savefile 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.
Affected Software
Event History
Frequently Asked Questions
Who is realistically exposed to exploitation?
Exposure is limited to deployments where an attacker can create or replace symbolic links inside the requesting user's pgAdmin storage directory. This generally requires filesystem access to the pgAdmin host or access to a shared or network-mounted storage backend.
What conditions must an attacker meet?
The attacker must be able to substitute a symbolic link at the final path component after the access check but before the file is opened for writing. They must also win this timing window; a link that already exists when the check runs is rejected.
What is the impact if exploitation succeeds?
The write can be redirected outside the user's storage directory, allowing creation or overwriting of an arbitrary file as the operating-system account that runs pgAdmin. The vulnerability affects integrity and availability, not confidentiality.
What can be done if an update is not immediately available?
Limit untrusted filesystem access to pgAdmin user storage directories and to any shared or network-mounted storage backend used for that storage. pgAdmin itself does not provide an interface for creating symbolic links, so preventing external link creation or replacement removes the stated prerequisite.