CVE Watch30 oct 2026

CVE-2026-116250

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

CVSS

6.5

Medio

EPSS

—

KEV

—

Exploit Today

—

0-100

Publicado: 30 oct 2026 · Última mod.: 30 oct 2026 · CWE-59 · CWE-367

EPSS · 30d

Sin historial EPSS suficiente todavía.

Descripción técnica

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.

Referencias oficiales

CVEs relacionados

CVECVSSEPSSKEVRExplotTítuloVis.

CVE-2026-1193367.8 ALT

—

———Pi-hole is a DNS sinkhole that protects devices from unwanted content without installing any client-side software. From 6.4.2 until 6.5, the root-run advanced/Scripts/updatecheck.sh cron job applies truncate -s 0 and chmod 644 to /etc/pihole/versions while following symbolic links in a directory owned by the pihole user. An attacker executing as pihole can replace that path with a symlink so the scheduled root operations truncate or create an arbitrary root-owned file, or race the operations so chmod makes a sensitive target world-readable without truncating it. This issue is fixed in version 6.5.2h CVE-2026-1193342.2 BAJ

—

———Pi-hole is a DNS sinkhole that protects devices from unwanted content without installing any client-side software. Prior to 6.5, gravity.sh checks file:// adlist readability with sudo -u pihole test -r but then allows curl, sometimes running as root, to normalize URL dot segments and open a different file. A pihole-readable decoy can therefore pass the check while curl reads a root-only target, and /proc/self paths can similarly resolve against different processes. Exploitation requires an administrator who can add adlists and can place a symlink and decoy on the filesystem. This issue is fixed in version 6.5.5h CVE-2026-1162406.5 MED

—

———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.5h CVE-2026-1197046.8 MED

—

———Bastille through 1.4.4 contains a symlink following vulnerability in the cp.sh, rcp.sh and jcp.sh subcommands that allows jailed users to escape jail isolation. Attackers inside a jail can plant symlinks pointing to host paths or other jail roots, so administrator-run copies overwrite or read host files with root privileges.6h CVE-2026-1192915.5 MED

—

———Zuke is a code-first, strongly typed build automation system for Deno. Prior to 1.4.0, @zuke/cli uses lstat to inspect scaffold names but then performs link-following reads, writes, and permission changes in zuke setup and zuke import. An attacker who supplies an untrusted cloned repository, template, or archive with a symbolic link at a scaffolded name can cause setup to overwrite a target outside the selected directory with the invoking user's permissions. The .gitignore path requires no flag, while --force permits a linked launcher target to be written and made executable; import can also read link-target content and incorporate it into the generated build file. This issue is fixed in version 1.4.0.8h CVE-2026-1156836.8 MED

—

———A race condition in Epiphany allows a malicious website to bypass the TLS/SSL certificate warning page. Epiphany registers the main-world script message handler "tlsErrorPage" so its internal TLS error page can implement "Accept Risk and Proceed". The handler was registered immediately before loading the error page, leaving a brief window where the previously loaded untrusted origin could still call window.webkit.messageHandlers.tlsErrorPage.postMessage(...). The only authorization check compares a numeric WebKit page id that increments predictably; an attacker can burst-guess ids and approve a certificate exception with no user click. If a victim visits malicious site A that redirects to site B with an invalid certificate, site A can, for a few milliseconds, disable TLS certificate error warnings for host B until Epiphany is restarted, enabling man-in-the-middle or site spoofing for that host. Upstream report: https://gitlab.gnome.org/GNOME/epiphany/-/work_items/2978 Proof of concept: https://beford.net/poc/ssl_poc.html Fix: https://gitlab.gnome.org/GNOME/epiphany/-/merge_requests/2245 (register handlers on LOAD_COMMITTED). No fixed release tagged yet; reporter and maintainer describe all current versions as affected. Maintainer notes the risky registration timing dates to commit 1da1caed (Epiphany 45.x era); before that the handlers were always registered and similarly reachable from web content.6h