Search
Search Results (4 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-104948 | 1 Enterprisedb | 1 Warehousepg | 2026-10-22 | N/A |
| WarehousePG (WHPG) 6.27.1 through 6.27.6 and 7.2.1 through 7.6.0 are affected by a missing authorization vulnerability (CWE-862) in the built-in cluster expansion functions gp_expand_lock_catalog() and gp_expand_bump_version(). Any authenticated database role can run them, and neither checks privileges. A low-privileged user can call gp_expand_lock_catalog() inside an open transaction to block all catalog changes across the cluster for every user, superusers included, until that transaction ends, which in practice requires a superuser to terminate the session. Blocked changes include DDL, temporary table creation, GRANT and CREATE ROLE. The same user can call gp_expand_bump_version() repeatedly. Each call disconnects sessions that hold temporary tables, with a FATAL error on their next catalog change, and makes every other session rebuild its segment connections. | ||||
| CVE-2026-104949 | 1 Enterprisedb | 1 Warehousepg | 2026-10-22 | N/A |
| WarehousePG (WHPG) 6.27.1 through 6.27.6 and 7.2.1 through 7.6.0 are affected by a missing authorization vulnerability (CWE-862) in gp_add_coordinator_standby(). The function is named gp_add_master_standby() in WHPG 6, and WHPG 7 keeps that name as an alias. Unlike the other segment add and remove functions, it does not require superuser privileges. A low-privileged user who can open a utility-mode connection can use it to add a fake standby coordinator entry to gp_segment_configuration on a cluster that has no standby configured. Administrators then cannot add a real standby until a superuser removes the fake entry. User data is not exposed or modified. | ||||
| CVE-2026-104947 | 1 Enterprisedb | 1 Warehousepg | 2026-10-21 | N/A |
| WarehousePG (WHPG) 7.2.1 through 7.6.0 is affected by a missing authorization vulnerability (CWE-862) in the built-in function gp_log_backend_memory_contexts(). Any authenticated database role can run this function without a GRANT. It also gets around the superuser restriction that PostgreSQL places on the underlying pg_log_backend_memory_contexts() function. A low-privileged user can force the segment backends of any other session, superuser sessions included, to write their memory context details to the segment server logs, which the attacker cannot read. Those details can include query text from other users' cached plans, and the call can be repeated to generate large amounts of log output. WarehousePG 6.x is not affected. | ||||
| CVE-2026-96538 | 1 Enterprisedb | 1 Warehousepg | 2026-09-28 | N/A |
| WarehousePG (WHPG) 7.x before 7.6.0-WHPG is affected by a missing authorization vulnerability (CWE-862) in the built-in server-side file functions pg_file_write(text,text,bool), pg_file_rename(text,text,text), pg_file_unlink(text), and pg_logdir_ls(). These functions are executable by any authenticated database role with no GRANT required, because the REVOKE that contrib/adminpack applies to the equivalent functions was never carried over to WHPG core when their catalog entries were repointed to the ungated adminpack-derived implementations as part of Greenplum's merge to a PostgreSQL 12 base. A non-superuser can use pg_file_write, pg_file_rename, and pg_file_unlink to create, overwrite (append), rename, and delete files under the data and log directories, and can use pg_logdir_ls() to enumerate log file names. Because postgresql.auto.conf resides in the data directory, a non-superuser can append configuration directives such as shared_preload_libraries or archive_command to it, resulting in arbitrary code execution as the postgres operating system user on the next server restart or configuration reload. WarehousePG 6.x is not affected, as the equivalent functions there enforce a superuser check internally. | ||||
Page 1 of 1.