PostgreSQL Anonymizer EUVD-2026-112288

Exploitation requires an authenticated PostgreSQL account (PR:L) on a server where the PostgreSQL Anonymizer salt and/or shift were configured at the database or role level via ALTER DATABASE or ALTER ROLE - the method the extension's own documentation recommends. The flaw is only reachable for a user who is NOT a member of pg_read_all_settings (members can already see these values through SHOW); for such a user the secrets nonetheless remain readable in the pg_db_role_setting or pg_roles catalog views. Limiting factors: the attacker must already hold valid database credentials, and no disclosure occurs if the salt was never set at the database/user level via those ALTER statements. Prior to version 3.3.0 the extension does not restrict these catalog-visible values.

This is a medium-severity information-disclosure issue (CVE-2026-105616, CVSS 5.7) in Dalibo's PostgreSQL Anonymizer extension, and the real-world signals point to a low-to-moderate, not emergency, priority. The vendor-supplied vector (AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:N/A:N) indicates a network-reachable but authenticated (PR:L) flaw whose only impact is confidentiality (C:H) - specifically exposure of the anonymization salt/shift secrets. KEV status is NO (not confirmed actively exploited), no EPSS score was provided, and there is no public exploit identified at time of analysis - the sole reference is a GitLab issue tracker entry, not working exploit code. The vuln.today decision label is 'this_month', consistent with a real but non-urgent fix window rather than act_now/emergency. One signal conflict worth flagging: the input vector sets UI:R (user interaction required), yet the described mechanism - a logged-in user directly querying pg_roles or pg_db_role_setting - needs no second-party interaction, so UI:R appears overstated; verify with the vendor. The C:H rating is defensible only because disclosure of the salt can undermine the entire pseudonymization scheme (allowing reversal of masked data), not because any primary database contents leak directly.

A low-privileged but authenticated PostgreSQL user who is NOT a member of pg_read_all_settings - and is therefore blocked from seeing the salt via SHOW - instead queries the pg_roles or pg_db_role_setting catalog views and reads the anonymization salt and shift that an administrator set using ALTER DATABASE or ALTER ROLE (the configuration method the PostgreSQL Anonymizer documentation recommends). With the salt recovered, the attacker can attempt to reverse pseudonymized/masked values. No public exploit code was identified; the attack is a straightforward catalog query requiring only database login.