Eymoutiers, France, Septembre 4th, 2026
Dalibo is pleased to announce PostgreSQL Anonymizer 3.2
introducing a new
panel of fast pseudonymization filters.
PostgreSQL Anonymizer
is an extension that hides or replaces personally
identifiable information (PII) or commercially sensitive data from a PostgreSQL
database.
The extension offers 6 different masking strategies:
Each strategy is complemented by an enhanced suite of Masking Functions, including advanced techniques such as: Substitution, Randomization, Faking, Pseudonymization, Partial Scrambling, Shuffling, Noise Addition and Generalization.
The extension can be installed with Debian and RPM packages, an Ansible role, a Docker image, etc. You can use it on most major DBaaS providers including : Alibaba Cloud, Crunchy Bridge, Google Cloud SQL, IBM Cloud, Microsoft Azure Database, Neon, Yandex It is also available on some Postgres forks such as EDB Advanced Postgres, Greenplum and Yugabyte.
See the INSTALL section of the documentation for more details!
Although Pseudonymization is not Anonymization, it may be useful in some contexts.
Until version 3.1, this was achieved with a panel of pseudo_*
functions,
such as anon.pseudo_last_name(...)
, anon.pseudo_email(...)
, etc.
These functions are now replaced by a new panel of anon.seeded_*
functions,
such as anon.seeded_last_name(...)
, anon.seeded_email(...)
, etc.
The anon.seeded_*
functions have 2 main advantages over the previous ones:
anon.seeded_street_name(id,'fr_FR')
The anon.pseudo_*
functions are kept for backward compatibility but are now
deprecated and will be removed in a future version. We encourage all users to
switch to the new anon.seeded_*
functions as soon as possible.
Version 3.2 includes fixes for 3 critical vulnerabilities allowing a user to gain superuser privileges under certain circumstances. The risk is very high on PostgreSQL 14 and on instances upgraded from PostgreSQL 14 and earlier.
These vulnerabilities are declared below:
All users should upgrade the extension to version 3.2 as soon as possible.
See issue 665 and issue 666 for more details.
Version 3.2 introduces a new security barrier that forbids superusers from using any kind of masking (static, dynamic, etc.). Enforcing the principle of "Least Privilege", the extension now refuses to run any masking function on behalf of a superuser.
Especially if you are currently using static masking, replica masking or backup masking with a superuser, we advise you to create a dedicated role for that.
The previous behaviour can be restored by setting anon.nosuperuser
to FALSE
,
in which case the security barrier will be removed and superusers will be able
to execute masking rules at their own risk.
The JSON schema used for imports / exports has changed between version 3.1 and 3.2. It is recommended to re-export the rules after the upgrade to 3.2
See the UPGRADE section for more details.
This release includes code, bugfixes, documentation, code reviews and ideas from Alain Lesage, Benoit Lobréau and other contributors. Kudos to Alain for his first contributions !
CVE-2026-19633 and CVE-2026-19634 were reported by Sarath Kumar, IITM Pravartak Security Team CVE-2026-83534 was reported by Alexander Kukushkin. Many thanks to them and to the PostgreSQL Security Team.
We would also like to thanks the people at Efluid who helped us with their ideas, comments and testing.
And also special thanks to the PGRX team for their amazing work!
PostgreSQL Anonymizer is part of the [Dalibo Labs] initiative. It is mainly developed by [Damien Clochard] and [Benoit Lobréau].
This is an open project, contributions are welcome. We need your feedback and ideas! Let us know what you think of this tool, how it fits your needs and what features are missing.
If you want to help, you can find a list of Junior Jobs.
Facts Only
* Dalibo released PostgreSQL Anonymizer version 3.2 on September 4th, 2026, in Eymoutiers, France.
* PostgreSQL Anonymizer is an extension for hiding or replacing PII and commercially sensitive data in PostgreSQL databases.
* The extension supports six masking strategies and functions including Substitution, Randomization, Faking, Pseudonymization, Partial Scrambling, Shuffling, Noise Addition, and Generalization.
* Installation methods include Debian and RPM packages, Ansible roles, and Docker images.
* Supported platforms include Alibaba Cloud, Crunchy Bridge, Google Cloud SQL, IBM Cloud, Microsoft Azure Database, Neon, Yandex, EDB Advanced Postgres, Greenplum, and Yugabyte.
* Version 3.2 replaces `anon.pseudo*` functions with `anon.seeded*` functions; the former are deprecated.
* Version 3.2 fixes three critical vulnerabilities (CVE-2026-19633, CVE-2026-19634, and CVE-2026-83534) that could allow superuser privilege escalation.
* High risk for these vulnerabilities exists on PostgreSQL 14 and instances upgraded from version 14 or earlier.
* A new security barrier prevents superusers from executing masking functions unless `anon.nosuperuser` is set to FALSE.
* The JSON schema for imports and exports has changed between version 3.1 and 3.2.
Executive Summary
Dalibo has released version 3.2 of the PostgreSQL Anonymizer extension, introducing critical security patches and functional updates. The update addresses three high-risk vulnerabilities—CVE-2026-19633, CVE-2026-19634, and CVE-2026-83534—which could allow unauthorized users to gain superuser privileges, particularly in environments using PostgreSQL 14 or earlier. To further harden security, the extension now implements a "Least Privilege" model that blocks superusers from performing masking operations by default, necessitating the creation of dedicated roles for static, replica, or backup masking.
Beyond security, the release transitions from `anon.pseudo*` to `anon.seeded*` functions for pseudonymization to improve performance and utility, though the previous functions remain for backward compatibility. Users are advised to upgrade immediately, re-export their rules due to a change in the JSON schema, and migrate to the new seeded functions. The extension remains broadly compatible across major DBaaS providers and various PostgreSQL forks.
Full Take
The strongest version of this narrative is a transparent, responsible disclosure of security vulnerabilities coupled with a product evolution aimed at better security hygiene. By explicitly naming CVEs and identifying the specific risk profile (PostgreSQL 14), the provider facilitates a precise risk assessment for database administrators.
However, the framing employs a classic security-driven urgency. By highlighting "critical vulnerabilities" and "very high" risk immediately following the announcement of new features, the narrative leverages a Fear Appeal to drive immediate adoption of version 3.2. This creates a forced binary: either upgrade immediately or remain exposed to superuser escalation. While the vulnerabilities are documented and likely genuine, the structure mirrors a vendor-driven push where the "solution" is the product update itself.
The shift toward "Least Privilege" by blocking superusers is a significant paradigm shift in the tool's philosophy. It acknowledges a fundamental truth in security: the most powerful account is the most dangerous vector. By forcing the creation of dedicated roles, the tool moves from being a mere utility to an enforcement mechanism for organizational security policy.
Patterns detected: ARC-0011 Fear Appeal
The root cause is the inherent tension between feature velocity and security stability in open-source extensions. The second-order consequence of this release is an increased administrative burden on users who must now restructure their role-based access control (RBAC) to comply with the new superuser restrictions.
Bridge Questions:
1. If a user disables the `anon.nosuperuser` barrier for convenience, what specific attack vectors are reopened?
2. How does the transition from "pseudo" to "seeded" functions change the mathematical predictability of the anonymized data?
Counterstrike Scan: A coordinated influence campaign would use these CVEs to trigger panic, claiming PostgreSQL is fundamentally broken to push a proprietary alternative. This content does not match that pattern; it provides specific fixes for a specific extension.
Sentinel — Human
The text exhibits characteristics of a formal software announcement, highly consistent with human-written technical documentation rather than synthetic news reporting.