What changed
On October 28, 2026, Dalibo announced PostgreSQL Anonymizer 3.3, describing fixes for 12 vulnerabilities in the extension used to mask personal or commercially sensitive data. The published list includes SQL-standard-body functions that expose unmasked values (CVE-2026-110181), pg_stats disclosure (CVE-2026-105615), salt disclosure through pg_db_role_setting (CVE-2026-105616), authentic statistics retained after static masking (CVE-2026-110183), security_invoker view and inherited-table masking gaps, cached-plan bypasses, subquery bypasses, data-modifying CTEs circumventing read-only restrictions, partial masking-function leakage, and two denial-of-service paths. Dalibo warns that some circumstances permit elevated or superuser privileges. Its upgrade guide explicitly says ALTER EXTENSION ... UPDATE is not supported: administrators must drop and recreate the extension when upgrading. Version 3.3 also forbids subqueries in masking rules, disables function inlining for transparent dynamic masking and restricts SQL-standard-body functions for masked roles.
Why it matters
Anonymization is often treated as a safe boundary between production customer data and lower-trust analysts, contractors or development environments. These flaws mean that a user subject to masking could in some configurations access original values or metadata, and some vulnerabilities could elevate privileges. Merely updating a PostgreSQL server package does not establish that the separate extension is patched. The extension's documented drop-and-recreate migration requires deliberate maintenance and masking-policy verification; administrators should also rotate anon.salt because disclosure could make existing pseudonymized values guessable. The new SQL-function restrictions may break queries using contrib extensions such as citext, earthdistance or pageinspect. No widespread exploitation has been established in the available sources, and this is not a claim that PostgreSQL core itself contains these flaws.
Twelve distinct security problems, not one generic data leak
The vendor's advisory names 12 CVEs. Some expose authentic column values through SQL functions, statistics, views, inherited tables or cached query plans. Others allow unsafe subqueries or data-modifying CTEs, and two target memory exhaustion or denial of service in masking helpers. These affect different paths and require the relevant roles, rules or database features to be in use; a CVE list alone does not establish that every installation is exploitable in the same way.
The migration trap: extension recreation, not ALTER EXTENSION UPDATE
The project's current upgrade guide says in-place ALTER EXTENSION ... UPDATE is unsupported. It instructs operators to drop and recreate the extension after every upgrade. Plan the change with a tested backup and a documented method to preserve or restore masking policies, permissions and dependencies; test the resulting access restrictions against actual roles and applications before reopening access. Verify the installed extension and package versions rather than assuming a PostgreSQL server update covers it.
Rotate the masking salt and review query compatibility
Dalibo recommends changing anon.salt because older versions could disclose it to malicious masked users, potentially enabling brute-force recovery of pseudonymized information. Subqueries in masking rules are now disallowed, and transparent dynamic masking disables function inlining. Masked users cannot execute functions with SQL-standard bodies; the documentation specifically warns that contrib extensions including citext, earthdistance, lo, pageinspect, pg_freespacemap and xml2 may be affected. Test any custom masking functions and dependent queries, and watch for performance regressions where query plans previously relied on inlining.
Evidence and boundaries
The release notice is a first-party Dalibo advisory carried by the PostgreSQL project, and the migration behaviour is documented in the project's own upgrade guide. The maintainer labels the vulnerabilities critical but does not provide individual CVSS scores or evidence of exploitation in the announcement. The affected component is PostgreSQL Anonymizer, not every PostgreSQL installation or all anonymization strategies by default.