https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 01 Nov 2026 09:32:13 +0000 https://db.gcve.eu/vuln/fkie_cve-2026-116240 <p>In server mode pgAdmin 4 validates a path into the user&#39;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:</p> <p>- 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 &#34;..&#34;, 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&#39;s storage directory name is a prefix of another&#39;s, another user&#39;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&#39;s directory.</p> <p>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 directorie…</p> <p>In server mode pgAdmin 4 validates a path into the user&#39;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:</p> <p>- 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 &#34;..&#34;, 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&#39;s storage directory name is a prefix of another&#39;s, another user&#39;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&#39;s directory.</p> <p>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 directorie…</p> https://db.gcve.eu/vuln/fkie_cve-2026-116240 https://db.gcve.eu/vuln/ghsa-wp8g-m28w-27c5 <p>In server mode pgAdmin 4 validates a path into the user&#39;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:</p> <p>- 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 &#34;..&#34;, 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&#39;s storage directory name is a prefix of another&#39;s, another user&#39;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&#39;s directory.</p> <p>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 directorie…</p> <p>In server mode pgAdmin 4 validates a path into the user&#39;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:</p> <p>- 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 &#34;..&#34;, 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&#39;s storage directory name is a prefix of another&#39;s, another user&#39;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&#39;s directory.</p> <p>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 directorie…</p> https://db.gcve.eu/vuln/ghsa-wp8g-m28w-27c5