CVE-2026-96538 in WarehousePG
Summary
by MITRE • 09/28/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/28/2026
The vulnerability identified in Greenplum Database (WarehousePG) versions prior to 7.6.0-WHPG represents a critical failure in access control mechanisms within the database server's administrative utility functions. This issue is classified under CWE-862, which denotes Missing Authorization, indicating that the system fails to properly verify whether an authenticated user has the necessary privileges to perform specific actions. The affected components are built-in server-side file manipulation functions including pg_file_write, pg_file_rename, pg_file_unlink, and pg_logdir_ls. These functions allow for direct interaction with the underlying operating system's file system, specifically targeting directories where database data and logs reside. In a secure configuration, such powerful operations should be restricted to superusers or explicitly granted roles due to their potential impact on system integrity and security. However, in this vulnerable version range, these functions are executable by any authenticated database role without requiring explicit GRANT statements, effectively bypassing standard permission checks that would normally restrict access to sensitive file operations.
The root cause of this vulnerability lies in a historical code integration error during the migration from Greenplum's previous architecture to a PostgreSQL 12 base. When Greenplum merged its core with PostgreSQL 12, it repointed catalog entries for these administrative functions to implementations derived from the contrib/adminpack module. In standard PostgreSQL distributions, the adminpack extension applies specific REVOKE statements that restrict access to superusers only. However, this critical security restriction was not carried over into the Greenplum core during the merge process. Consequently, while equivalent functions in WarehousePG 6.x correctly enforce a superuser check internally, versions 7.x through 7.5.x lack this safeguard. This discrepancy creates an authorization bypass where any user with basic authentication credentials can invoke these file management routines as if they possessed administrative privileges, despite lacking the necessary role permissions within the database schema.
The operational impact of this vulnerability is severe because it allows a non-superuser to manipulate files in critical directories such as the data directory and log directories. Specifically, an attacker can use pg_file_write to create or overwrite configuration files, pg_file_rename to alter file names, pg_file_unlink to delete essential files, and pg_logdir_ls to enumerate existing log files for reconnaissance purposes. The most dangerous aspect of this flaw is its potential to lead to arbitrary code execution as the postgres operating system user. Since the postgresql.auto.conf file resides in the data directory, an attacker can append malicious configuration directives such as shared_preload_libraries or archive_command to this file. When the database server restarts or reloads its configuration, it will load these libraries or execute commands specified by the attacker, granting them full control over the underlying operating system with the privileges of the postgres user. This escalation from a low-privilege database account to high-level OS access compromises confidentiality, integrity, and availability of all data managed by the instance.
From a threat modeling perspective, this vulnerability aligns with MITRE ATT&CK techniques related to privilege escalation and command execution via system configuration manipulation. The ability to modify shared_preload_libraries is particularly significant as it allows for the loading of dynamic libraries that execute code during server startup, effectively bypassing runtime security controls. This scenario exemplifies a classic path traversal or unauthorized file write vulnerability leading to remote code execution, which is often categorized under CWE-94 in contexts involving injection into configuration files. The lack of input validation and authorization checks on these administrative functions creates an attack vector that does not require complex exploitation techniques; simple SQL commands issued by any authenticated user are sufficient to trigger the flaw.
Mitigation strategies must address both immediate remediation and long-term architectural fixes. The primary solution is to upgrade Greenplum Database to version 7.6.0-WHPG or later, where this authorization check has been properly implemented in the core codebase. For environments that cannot immediately upgrade, temporary mitigations should include restricting database access to only trusted users with superuser privileges and ensuring that no non-privileged accounts have direct login capabilities unless absolutely necessary for specific application functions that do not require file system interaction. Additionally, implementing strict network segmentation to limit exposure of the database port can reduce the attack surface. It is also advisable to audit existing user roles and revoke any unnecessary permissions related to administrative packages or extensions until the patch is applied. Regular monitoring of configuration files like postgresql.auto.conf for unauthorized changes can provide early detection indicators if exploitation attempts occur before a fix is deployed.