Answer in brief
CVE-2026-96538 records a High severity (CVSS 8.7) vulnerability in WarehousePG pg_file_write/pg_file_rename/pg_file_unlink/pg_logdir_ls privilege escalation. The current sources do not mark it as known exploited. The current feed maps EnterpriseDB/WarehousePG (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 8.7. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps EnterpriseDB/WarehousePG (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| EnterpriseDB/WarehousePGgeneric | >=7.0.0 <7.6.0-WHPG | 7.6.0-WHPG |
Published upstream
Sep 28, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Sep 28, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Sep 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.
Quoted source text, attributed separately from HOL analysis.