Search
Search Results (3 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-61818 | 1 Pgxn | 1 Pg Partman | 2026-09-19 | 8.5 High |
| pg_partman is a PostgreSQL extension that manages partitioned tables by time or ID. Prior to 5.5.0, undo_partition() reads part_config.time_encoder as unrestricted text and interpolates it without identifier quoting into a dynamically executed SELECT statement. A role with partman_user access can store SQL rather than a function name, and the SQL executes with the privileges of the caller that invokes undo_partition(). The function is not part of the default background-worker path, which limits the automatic superuser escalation described by the related create-partition vulnerability, but a privileged caller can still have its available confidentiality, integrity, and availability permissions abused. This issue is fixed in version 5.5.0. | ||||
| CVE-2026-61817 | 1 Pgxn | 1 Pg Partman | 2026-09-19 | 8.5 High |
| pg_partman is a PostgreSQL extension that manages partitioned tables by time or ID. Prior to 5.5.0, run_maintenance(), show_partitions(), show_partition_info(), undo_partition(), and partition_data_time() interpolate the writable part_config.time_dncoder text value without identifier quoting into dynamic SQL. A role with the documented partman_user privileges can store SQL rather than a decoder function name. When an affected operation later uses the poisoned value, including pg_partman_bgw maintenance for a text- or UUID-keyed set, the SQL executes with the operation's privileges, which can be the default PostgreSQL superuser background-worker role. The persistent row can restore elevated access on later ticks, and successful exploitation can permit database-wide compromise and operating-system command execution as the PostgreSQL service account. This issue is fixed in version 5.5.0. | ||||
| CVE-2021-33204 | 1 Pgxn | 1 Pg Partman | 2024-11-21 | 9.8 Critical |
| In the pg_partman (aka PG Partition Manager) extension before 4.5.1 for PostgreSQL, arbitrary code execution can be achieved via SECURITY DEFINER functions because an explicit search_path is not set. | ||||
Page 1 of 1.