CVE-2026-105614

PostgreSQL Anonymizer before 3.3.0 leaves statistics about the original data visible in pg_stats until an ANALYZE operation is performed on the table, either manually or by autovacuum. This can expose information about masked data.

The anon.partial() and anon.partial_email() functions in PostgreSQL Anonymizer before 3.3.0 can reveal the whole data if the data is small enough. The issue is fixed in version 3.3.0.

PostgreSQL Anonymizer before 3.3.0 mishandles anonymization functions defined using SQL-standard function bodies. PostgreSQL analyzes such functions at declaration time while Anonymizer only checks them at execution time, which can be exploited by any user with the TEMPORARY privilege.

PostgreSQL Anonymizer before 3.3.0 does not mask data returned by a sub-query in a rule. The problem is resolved in version 3.3.0.

PostgreSQL Anonymizer before 3.3.0 does not mask data accessed through a security_invoker view. The problem is resolved in version 3.3.0.

PostgreSQL Anonymizer's documentation recommends applying rules on partitions and inheritance tables, but direct access to partitions is masked while access through the parent table is not. The problem is resolved in version 3.3.0.

PostgreSQL Anonymizer before 3.3.0 does not invalidate plans prepared after a rule was added or a role changed. Users using such plans can still see unmasked data until the end of the session.

PostgreSQL restricts access to the salt and shift via the SHOW command for users not in pg_read_all_settings, but they are visible in pg_db_role_setting or pg_roles if set on the database, user, or both. PostgreSQL Anonymizer's documentation recommends using ALTER DATABASE / ALTER ROLE for the salt; the problem is resolved in version 3.3.0.

PostgreSQL's optimized statistics on a table are visible to anyone with SELECT privilege on that table. A masked role can therefore read a limited subset of data through the statistics view's histograms and MCVs.

PostgreSQL Anonymizer's range-based dummy functions do not constrain the range size. This can be exploited to exhaust backend memory and OOM-kill it (when overcommit is on), resulting in cluster-wide crash recovery.