PostgreSQL Anonymizer 3.2 fixes security issues and blocks masking executed as a superuser. An upgrade must therefore examine the roles used by existing jobs, their backups and their results, rather than disable the protection to keep old scripts running.
Date the announcement correctly and identify the component
The PostgreSQL Anonymizer 3.2 release announcement is dated 4 September 2026; PostgreSQL.org republished it on 9 September. The event is the announcement of 4 September, without assuming an availability time. PostgreSQL Anonymizer is an extension: its fixes and preconditions do not apply indiscriminately to all of PostgreSQL. [PostgreSQL.org announcement]
Version 3.2 announces the blocking of masking executed by a superuser and the gradual migration from pseudo_* to seeded_*, according to the publisher's announcement.
An independent report describes two distinct privilege-escalation paths reproduced on 3.1.3: the first involves a table owner without a second privileged actor; the second requires a privileged operator to import a rules file whose contents have been influenced by an attacker. These preconditions establish neither active exploitation nor all affected versions. [report 665]
Inventory jobs and roles
A role is an identity to which PostgreSQL attaches permissions; a superuser has privileges beyond those of a typical application role. Pseudonymization replaces a value with another to limit its direct identification. Determinism means that, with the same parameters, the same input can produce the same output; a collision occurs when distinct inputs produce the same value. The locale is the language and region setting that influences some formats. Static masking modifies data, a replica produces a copy and an export produces an external dataset: these modes cannot be assessed with the same permissions.
Start by documenting the extension version, masking mode and effective identity, without executing a job or modifying a production database. Do not disable anon.nosuperuser to bypass the new safeguard.
| Environment | Version | Mode | Effective role | Owner | Operation | Permission to confirm | Evidence |
|---|---|---|---|---|---|---|---|
| To be completed | To be checked | Static, replica or export | To be checked | To be assigned | To be described | To be confirmed | To be attached |
Validate a dedicated role in testing
Minimum permissions follow from the functions actually used and the documentation for the target version; there is no universal permission-granting command (GRANT) suitable for every job. A proposed plan, not executed, starts with an authorized test restore and synthetic data. It checks execution, errors, backup and recovery, then retains a rollback based on a validated restore, rather than disabling a safeguard or making an improvised switch.
This plan also includes relationships, null values, collisions and repetition: check that a relationship remains usable, that a null value retains the expected behavior, that collisions are measured and that repeated results match the property sought. Determinism does not guarantee anonymity. [function documentation]
Exclusively synthetic example: three fictional people, P01, P02 and P03, have Personne_A, Personne_B and Personne_A respectively in a name field; P03 has a null optional value. Two fictional orders, C01 and C02, are linked to P01 and P02. The locale, the same parameters and the same starting value (the “seed”) are recorded for repeated runs. None of these records is real.
| Case | Expected outcome | Evidence |
|---|---|---|
| Relationships C01→P01 and C02→P02 | Consistent references after processing | NOT EXECUTED |
| Null value P03 | Behavior documented and preserved | NOT EXECUTED |
| Collision Personne_A / Personne_B | Collision measured, not assumed absent | NOT EXECUTED |
| Repetition with the same seed and parameters | Result compared for the intended determinism | NOT EXECUTED |
| Old and new function names | Compared without requiring equal values | NOT EXECUTED |
| Schema constraints | Result checked | NOT EXECUTED |
Treat the fix as a controlled change
The new seeded_* family is gradually replacing pseudo_*, which are retained for compatibility in 3.2 but deprecated, meaning they are intended for removal later. No correspondence of identical values should be assumed. Check the locale, available functions and expected results in the target version. [3.2 announcement]
Proposed plan, not executed: inventory; backup of configuration, roles and synthetic data; isolated restore; validation of a dedicated role; tests; decision to stop or switch over; rollback proven through restoration. This is not a blind return to an earlier extension version. For the continuity and recovery framework, see the continuity and recovery plan.
The job owner defines the expected results; the administrator validates permissions and restoration; the team using the data confirms that relationships and constraints remain usable. A failed restore, an unexplained permission or a data inconsistency suspends the switchover. This small dataset can verify the method: it does not measure the overall collision risk or resistance to reidentification on real data. Consulting the documentation for the installed version remains necessary; latest pages can change.