PostgreSQL Anonymizer EUVD-2026-72142

Exploitation requires the attacker to hold at minimum a regular PostgreSQL user account with the ability to create or modify a JSON document that a superuser will subsequently import using anon.import_database_rules() or anon.import_roles_rules(). The PostgreSQL Anonymizer extension must be installed and the import workflow must be actively used. Exploitation is limited by three concrete factors: (1) the attacker must have write access to contribute the malicious JSON rules document; (2) a superuser must actively invoke one of the two import functions after the malicious document is planted - this is a required user-interaction step and cannot be forced remotely; and (3) the extension must be deployed and the import functions must be part of the operational workflow. Default PostgreSQL installations without the extension installed are not affected.

The vendor-supplied CVSS score of 6.4 (AV:N/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:H) reflects the multi-step nature of the attack and the dependency on superuser interaction. However, the PR:H metric appears inconsistent with the description, which states that 'a user' - not a superuser - creates the malicious JSON; this suggests PR:L is more accurate for the attacker's initial step, which would push the base score toward 7.5. This discrepancy should be verified with Dalibo. The AC:H and UI:R metrics are well-grounded: exploitation requires the attacker to successfully plant a document that a superuser will later import, creating an indirect, social-engineering-dependent exploitation path. There is no EPSS data or CISA KEV listing available, and no public exploit has been identified, indicating no confirmed active exploitation at time of analysis. Practical risk is elevated in deployments where database roles are loosely separated and untrusted users can contribute or modify anonymization rule files.

An attacker with a regular database account creates a JSON anonymization rules document in which one object name (e.g., a column identifier) contains embedded SQL such as a COPY command or a superuser password-change statement. During a routine anonymization configuration refresh, a database superuser calls anon.import_database_rules() to load the new rules; the injected SQL executes with superuser privileges, granting the attacker the ability to read all data, modify any table, or create backdoor superuser accounts.