CVE-2026-110181

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 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.

The anon.image_blur() function in PostgreSQL Anonymizer before 3.3.0 does not check the declared dimensions of the provided image, allowing an attacker to supply a small image with enormous declared dimensions. This can exhaust backend memory and cause an OOM-kill, resulting in cluster-wide crash recovery.

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.