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 gpaddcoordinatorstandby(). The function is named gpaddmasterstandby() 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 gpsegmentconfiguration 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.

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 gpexpandlockcatalog() and gpexpandbumpversion(). Any authenticated database role can run them, and neither checks privileges. A low-privileged user can call gpexpandlockcatalog() 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 gpexpandbumpversion() 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.

WarehousePG (WHPG) 7.2.1 through 7.6.0 is affected by a missing authorization vulnerability (CWE-862) in the built-in function gplogbackendmemorycontexts(). Any authenticated database role can run this function without a GRANT. It also gets around the superuser restriction that PostgreSQL places on the underlying pglogbackendmemorycontexts() 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.

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 pgfilewrite(text,text,bool), pgfilerename(text,text,text), pgfileunlink(text), and pglogdirls(). 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 pgfilewrite, pgfilerename, and pgfileunlink to create, overwrite (append), rename, and delete files under the data and log directories, and can use pglogdirls() to enumerate log file names. Because postgresql.auto.conf resides in the data directory, a non-superuser can append configuration directives such as sharedpreloadlibraries or archivecommand 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.