PostgreSQL Anonymizer CVE-2026-13455

Exploitation requires an authenticated database user holding a masked role with execute permission on anon.hash() - the standard configuration for any masked user in a PostgreSQL Anonymizer deployment, making this the default operational state rather than a special configuration. The attacker must supply arbitrary seed inputs and collect a sufficient volume of (seed, hash_output) pairs for offline brute-force; the number required depends on the salt length and underlying hash algorithm, neither of which is specified in the advisory. Limiting factors: the attacker must possess valid database credentials with a masked role assignment; the brute-force phase requires offline compute resources; and the attack is not instantaneous, requiring a sustained data-collection phase that may be observable in query logs. Deployments where masked roles are restricted exclusively to fully-trusted internal users with monitored access face substantially lower realistic risk. No non-default configuration is required - the vulnerability is present in the baseline use of the extension.

The CVSS 4.3 Medium score (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) reflects a network-reachable, low-complexity attack requiring low privileges with confidentiality-only, partial impact. The C:L rating may understate real-world impact: recovering the salt enables reversal of all pseudonymized columns in the database, not a single record - the systemic exposure is disproportionate to the partial-impact designation. No EPSS data was supplied; no KEV listing exists; no public POC has been identified, placing this in the no-active-exploitation category at time of analysis. AC:L is justified because the collection phase (repeated anon.hash() calls) involves no special conditions beyond holding a masked role, which is the extension's baseline operational mode. The risk is most acute in deployments where masked roles are granted to semi-trusted parties such as external analysts or contractors, which is the primary stated use case for PostgreSQL Anonymizer - meaning the attacker profile is exactly the population the extension is designed to handle. Post-patch, organizations should rotate the anonymization salt, since collected pairs from before the upgrade remain usable offline against the old salt.

A database analyst granted a masked role on a PostgreSQL instance running a vulnerable version of PostgreSQL Anonymizer connects over the network and invokes anon.hash() with a large dictionary of known seed values, accumulating thousands of (seed, output) pairs over multiple sessions. The attacker processes these pairs offline using brute-force or dictionary techniques to recover the salt. With the salt in hand, the attacker uses the same hash function to reverse every pseudonymized column in the database, exposing the original sensitive personal data that the extension was deployed to protect.