CVE-2026-104948 in WarehousePG
Summary
by MITRE • 10/22/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in WarehousePG versions 6.27.1 through 6.27.6 and 7.2.1 through 7.6.0 represents a critical failure in access control mechanisms within the database engine's cluster expansion subsystem. This flaw is classified under CWE-862, which denotes Missing Authorization, indicating that the software fails to properly verify whether an authenticated user has the necessary privileges to execute specific administrative functions. Specifically, two internal procedures designed for managing cluster state, gp_expand_lock_catalog() and gp_expand_bump_version(), are exposed in a manner that allows any authenticated database role to invoke them without restriction. In a secure architecture, such low-level operational commands should be restricted exclusively to superusers or roles with explicit administrative privileges to prevent misuse by standard users. The absence of these checks creates a significant security gap where the boundary between regular user operations and system administration is effectively dissolved for these specific functions.
The operational impact of exploiting gp_expand_lock_catalog() is severe, leading to a denial-of-service condition that affects all users connected to the database cluster, including superusers. When an authenticated user with low privileges executes this function within an open transaction, it acquires locks on catalog tables that persist until the transaction concludes. Because these locks prevent any modifications to the system catalogs, they effectively halt critical database operations such as Data Definition Language statements like CREATE or ALTER TABLE, the creation of temporary tables, and privilege management commands like GRANT or CREATE ROLE. This state persists indefinitely from the perspective of other users, requiring a superuser to manually terminate the offending session to restore normal cluster functionality. This mechanism allows a single low-privileged user to effectively paralyze the entire database environment by holding these locks open for an extended period, thereby disrupting business continuity and availability.
A second vector of impact arises from the misuse of gp_expand_bump_version(). While this function does not lock catalogs in the same manner as its counterpart, it triggers disruptive side effects when called repeatedly by a low-privileged user. Each invocation causes active sessions that hold temporary tables to be disconnected with a fatal error upon their next attempt to modify catalog data. Furthermore, every other session connected to the cluster is forced to rebuild its connections to the database segments. This behavior introduces significant instability and performance degradation across the distributed system. The repeated disconnection of user sessions and the overhead associated with re-establishing segment connections can lead to widespread latency spikes, dropped queries, and potential resource exhaustion on both client applications and server processes.
From a threat modeling perspective, this vulnerability aligns with MITRE ATT&CK techniques related to Denial of Service and Privilege Escalation through misconfiguration or logic flaws. Although the attacker does not gain direct administrative privileges, they achieve an effect equivalent to privilege escalation by forcing superusers into emergency maintenance modes or causing service outages that only privileged accounts can resolve. The vulnerability exploits the trust model inherent in database authentication systems, where successful login is often assumed to imply sufficient authority for all available commands unless explicitly restricted. To mitigate this risk, immediate patching to a version beyond 6.27.6 and 7.6.0 is required if available. In environments where patching is not immediately feasible, administrators should implement strict network-level access controls to limit database connectivity to trusted hosts only. Additionally, reviewing and restricting the execution permissions of internal system functions via role-based access control policies can provide a temporary layer of defense by ensuring that such low-level administrative procedures are inaccessible to standard user roles until permanent remediation is applied.