PostgreSQL Anonymizer CVE-2026-11945

Attacker must (1) hold an authenticated PostgreSQL role with the ability to write the JSON rules document later consumed by the anon extension (e.g., insert into the rules table, modify the file on disk, or supply the file path) and (2) wait for or induce a superuser to invoke anon.import_database_rules() or anon.import_roles_rules() against that JSON. Exploitation is LIMITED by: requiring an existing database account (PR:L), requiring the anon extension to be installed at a version below 3.1.1, requiring a superuser to actually run one of the two named import functions on attacker-influenced input, and the malicious payload must be placed in the specific vulnerable JSON key-value pair identified by the vendor. No special PostgreSQL configuration beyond having the anon extension installed and using its rule-import workflow.

Signals here pull in opposite directions and must be weighed carefully: the CVSS 3.1 base score of 7.5 (AV:N/AC:H/PR:L/UI:N/C:H/I:H/A:H) reflects total compromise of the database, but EPSS is only 0.04% (12th percentile) and CISA SSVC marks Exploitation as none and Automatable as no. The vector lists UI:N, yet the description requires a superuser to invoke the importer against attacker-supplied JSON - that is effectively a deferred user/admin action, so the AV:N/UI:N rating likely understates the social/operational gating. PR:L is consistent with the requirement that the attacker first be an authenticated database user able to write the JSON rules file or row. The CVE is not in CISA KEV and no POC is referenced. Net assessment: high impact but low likelihood - prioritize patching in environments where rule import is performed by superusers and where untrusted users can influence the rules JSON, but it is not an emergency for instances where only trusted operators produce the rules file.

A low-privileged but authenticated database user who can influence the masking/role rules JSON (for example by writing to a shared rules table or file consumed during restore) embeds malicious SQL inside the targeted key-value pair. Later, a DBA running maintenance executes SELECT anon.import_database_rules(...) or anon.import_roles_rules(...) as a superuser, at which point the embedded SQL runs with superuser privileges and the attacker creates a new superuser role or exfiltrates protected data. No public exploit identified at time of analysis, but the pattern is a straightforward CWE-89 string-interpolation injection once the offending JSON key is identified.