Warehousepg
Monthly
Missing authorization in WarehousePG (WHPG) 7.x before 7.6.0-WHPG lets any authenticated database role - with no superuser rights, no GRANT, and no special role membership - call the built-in server-side file functions pg_file_write, pg_file_rename, pg_file_unlink and pg_logdir_ls, 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 _v1_1 implementations during the merge onto a PostgreSQL 12 base. An attacker holding ordinary database credentials can therefore create, append to, overwrite, rename and delete files under the data and log directories and enumerate log file names, and by appending directives such as shared_preload_libraries or archive_command to postgresql.auto.conf can achieve arbitrary code execution as the postgres operating system user on the next server restart or configuration reload. WarehousePG 6.x is not affected because its equivalent functions enforce an internal superuser check, and no public exploit code has been identified at time of analysis (no CISA KEV entry).
Missing authorization in WarehousePG (WHPG) 7.x before 7.6.0-WHPG lets any authenticated database role - with no superuser rights, no GRANT, and no special role membership - call the built-in server-side file functions pg_file_write, pg_file_rename, pg_file_unlink and pg_logdir_ls, 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 _v1_1 implementations during the merge onto a PostgreSQL 12 base. An attacker holding ordinary database credentials can therefore create, append to, overwrite, rename and delete files under the data and log directories and enumerate log file names, and by appending directives such as shared_preload_libraries or archive_command to postgresql.auto.conf can achieve arbitrary code execution as the postgres operating system user on the next server restart or configuration reload. WarehousePG 6.x is not affected because its equivalent functions enforce an internal superuser check, and no public exploit code has been identified at time of analysis (no CISA KEV entry).