pg_partman EUVD-2026-83422

Requires an authenticated database role that has been granted partman_user access to the pg_partman configuration tables (PR:L) - this is the single hard prerequisite and is not the default for ordinary users. The attacker must be able to INSERT or UPDATE rows in part_config, including setting a low maintenance_order value, and must craft a row that reliably raises an exception during run_maintenance(). Impact is realized only when scheduled maintenance runs (typically the pg_partman background worker or a cron-invoked run_maintenance()). No user interaction and no non-default product configuration are needed beyond having partition sets under active maintenance. Affected: pg_partman prior to 5.5.0; risk is most material in multi-tenant/shared clusters where multiple roles hold partman_user.

This is a genuine but modest-severity availability issue, and the raw CVSS 6.5 (MEDIUM) is a fair reflection of real-world risk. The vendor CVSS vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) is internally consistent with the description and with CWE-703 (improper handling of exceptional conditions): the only impact is availability (A:H) - loss of automated partition maintenance database-wide - with no confidentiality or integrity impact. Critically, the input Tags include 'Information Disclosure', which directly contradicts the CVSS vector (C:N) and the description; this is a DoS/availability flaw, not information disclosure - the tag is mislabeled. No EPSS score, no CISA KEV listing, and no public POC are provided, so exploitation likelihood signals are absent. Exploitation requires an authenticated role holding partman_user access (PR:L), which meaningfully limits the attacker population to insiders/tenants who already have partition-management rights - this is more an insider/multi-tenant abuse or misconfiguration risk than an internet-facing threat. The 'network' attack vector (AV:N) reflects that the malicious row is inserted via an ordinary SQL connection, not that it is unauthenticated. Overall: a real, low-friction denial of maintenance for a privileged DB role, but not a drop-everything priority.

In a shared PostgreSQL environment, a user with partman_user access inserts or updates a part_config row that is guaranteed to fail during maintenance and assigns it a low maintenance_order so it is processed first. On each subsequent maintenance tick, run_maintenance() hits the exception on that poisoned row and, because the exception is handled outside the row loop, immediately aborts before maintaining any legitimate partition sets. No public exploit code is identified at time of analysis; the technique is trivial given the required privilege.