Daily Digest
The most urgent item in today's database digest is the cluster of three HIGH-severity CVEs (CVSS 8.5) affecting the pg_partman PostgreSQL extension, all unresolved prior to version 5.5.0. These vulnerabilities allow a low-privilege `partman_user` role to inject arbitrary SQL or relocate tables between schemas via background-worker privileges that default to PostgreSQL superuser, potentially enabling database-wide compromise and OS command execution as the PostgreSQL service account. While none of these entries are currently CISA KEV-confirmed, the combination of network-reachable attack surface, low privilege requirements, and superuser-level impact makes immediate patching the top priority for any PostgreSQL deployment using pg_partman.
Summary: The pg_partman extension interpolates the `part_config.time_encoder` text value without identifier quoting into dynamic SQL in functions including `run_maintenance()`, `show_partitions()`, `show_partition_info()`, `undo_partition()`, and `partition_data_time()`. A role with `partman_user` privileges can store SQL instead of a decoder function name; when a subsequent operation (including `pg_partman_bgw` maintenance for text- or UUID-keyed sets) uses the poisoned value, the SQL executes with the operation's privileges—potentially the default PostgreSQL superuser background-worker role. Successful exploitation permits database-wide compromise and OS command execution as the PostgreSQL service account. The persistent poisoned row can restore elevated access on later maintenance ticks. Fixed in version 5.5.0.
Affected Features / Interoperability: The `pg_partman` extension's partition management functions (`run_maintenance`, `show_partitions`, `show_partition_info`, `undo_partition`, `partition_data_time`) and the background worker process (`pg_partman_bgw`). Downstream impacts include potential breakage of automated partition maintenance schedules, replication setups relying on pg_partman-managed partitions, and any client applications or extensions that interact with partitioned tables managed by pg_partman.
Source:
Actions:
Summary: In pg_partman 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 that SQL executes with the privileges of the caller invoking `undo_partition()`. While `undo_partition()` is not part of the default background-worker path (limiting automatic superuser escalation compared to the related create-partition vulnerability), a privileged caller can still abuse available confidentiality, integrity, and availability permissions. Fixed in version 5.5.0.
Affected Features / Interoperability: The `undo_partition()` function within pg_partman. Downstream impacts include potential data exposure or corruption when `undo_partition()` is invoked by privileged roles, and any automation or scripts that call `undo_partition()` as part of partition lifecycle management.
Source:
Actions:
Summary: In pg_partman prior to 5.5.0, `drop_partition_id()` and `drop_partition_time()` use `part_config.retention_schema` as the target for `ALTER TABLE SET SCHEMA` and accept any nonempty schema name. A role with `partman_user` access can select a target schema where the role lacks the normal `CREATE` privilege, and the background worker performs the relocation with `pg_partman_bgw.role` privileges (defaulting to PostgreSQL superuser), bypassing the authorization check that a normal `ALTER TABLE SET SCHEMA` operation would enforce. This permits unauthorized relocation of retained child tables between schemas. Fixed in version 5.5.0.
Affected Features / Interoperability: The `drop_partition_id()` and `drop_partition_time()` functions and the `pg_partman_bgw` background worker. Downstream impacts include unauthorized schema relocation of retained partition child tables, potential breakage of schema-dependent access controls, and disruption of any applications or queries that reference tables by schema-qualified names.
Source:
Actions:
PostgreSQL:
MySQL:
Oracle Database:
Microsoft SQL Server:
No CISA KEV‑confirmed vulnerabilities were reported for the scoped cloud services today; the most urgent items come from unverified news chatter, highlighted by an AWS‑related report describing how researchers used Anthropic’s Claude Opus 5 to chain two flaws and take over OpenAI staff accounts, underscoring possible AI‑tool supply‑chain risks.