WarehousePG EUVD-2026-107264

Two concrete prerequisites: (1) the attacker must hold a valid low-privileged account able to open a utility-mode connection to the coordinator (PR:L - authenticated), and (2) the target cluster must currently have NO standby coordinator configured, which is exactly the attack requirement captured by AT:P - gp_add_coordinator_standby()/gp_add_master_standby() is the one add/remove function missing the superuser check that its siblings enforce. Limiting factors that reduce real-world risk: it is useless on clusters that already have a standby configured, it cannot read or modify user data (confidentiality unaffected), and remediation requires only that a superuser delete the fake gp_segment_configuration entry. It affects only WarehousePG 6.27.1-6.27.6 and 7.2.1-7.6.0.

This is a genuinely low-priority issue, and the signals are consistent rather than conflicting. The vendor-supplied CVSS 4.0 vector scores only 2.3 (Low): network vector (AV:N) and low complexity (AC:L), but it requires authenticated low-privileged access (PR:L) and carries an explicit attack requirement (AT:P) - the target cluster must have no standby coordinator configured. Impact is bounded to limited integrity (VI:L) and limited availability (VA:L) of the configuration/standby subsystem, with no confidentiality impact (VC:N); the description confirms user data is neither exposed nor modified. No EPSS score, KEV listing, POC, or SSVC decision data was provided in the input - absence of these is not itself evidence of safety, but combined with the low CVSS and the authenticated+preconditioned nature of the flaw, there is no indication of a widespread or urgent threat. The realistic worst case is a nuisance/soft-DoS: a low-privileged user plants a fake standby entry that an administrator cannot clear without superuser intervention. This is a high-CVSS-but-no - rather a correctly-scored low-risk authorization gap that should be patched in routine maintenance, not emergency cycles.

A low-privileged but authenticated user on a WarehousePG cluster that has no standby coordinator opens a utility-mode connection and invokes gp_add_coordinator_standby() (aka gp_add_master_standby()), which - unlike sibling segment functions - omits the superuser check. This inserts a bogus standby entry into gp_segment_configuration, after which administrators are blocked from provisioning a legitimate standby until a superuser manually removes the fake record. No public exploit identified at time of analysis.