CVE-2026-97469 in PostgreSQL Anonymizer
Summary
by MITRE • 09/25/2026
PostgreSQL Anonymizer contains a vulnerability that allows unprivileged masked users to repeatedly call the anon.hash() function and collects (seed, hash_output) pairs to perform an offline brute-force attack and deduce the salt. A masked role can run a RESTRICTED function when the call is placed inside the sub-select. The problem is resolved in PostgreSQL Anonymizer 3.2.3 and later versions
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/25/2026
The vulnerability identified within the PostgreSQL Anonymizer extension represents a significant flaw in access control logic, specifically concerning the enforcement of restrictions on masked database roles. This issue allows unprivileged users who have been granted specific masking permissions to bypass intended security boundaries by exploiting how function calls are evaluated within sub-select statements. The core technical failure lies in the inability of the system to properly restrict certain functions when they are invoked indirectly through nested queries, effectively creating a loophole that undermines the principle of least privilege applied to data anonymization workflows.
At the heart of this vulnerability is the anon.hash() function, which utilizes a salt value to generate deterministic hashes for sensitive data fields. Under normal operational circumstances, masked roles should be restricted from accessing or manipulating the underlying cryptographic parameters such as salts and seeds. However, by placing calls to anon.hash() inside a sub-select clause, an attacker can repeatedly execute this function with varying inputs while capturing the resulting hash outputs alongside their corresponding seed values. This capability transforms what is intended to be a secure anonymization tool into a mechanism that facilitates offline brute-force attacks against the salt itself.
The operational impact of this flaw is severe for organizations relying on PostgreSQL Anonymizer for data privacy compliance and security. By collecting pairs of seeds and hash outputs, an attacker can perform statistical analysis or brute-force techniques to deduce the original salt used by the system. Once the salt is compromised, the integrity of all hashed sensitive data stored in the database is potentially at risk. Attackers could reverse-engineer previously anonymized records if they possess additional contextual information about the plaintext values, thereby defeating the primary purpose of using cryptographic hashing for privacy protection. This undermines trust in the database's ability to safeguard personally identifiable information and other regulated data types.
This vulnerability aligns with CWE-284 Improper Access Control, as it involves a failure to properly restrict access rights for users lacking appropriate privileges. Furthermore, from an offensive security perspective, this technique relates to ATT&CK T1078 Valid Accounts, where attackers leverage legitimate credentials and system features to escalate their capabilities or extract sensitive data without triggering immediate detection mechanisms typical of unauthorized intrusion attempts. The exploitation relies on the misconfiguration or insufficient validation within the extension's permission model rather than a buffer overflow or injection flaw, highlighting the complexity of securing complex database extensions with granular access controls.
To mitigate this risk, organizations must upgrade to PostgreSQL Anonymizer version 3.2.3 or later, where the developers have addressed the logic error allowing restricted functions to be executed via sub-selects. In addition to applying the software patch, administrators should review their current masking policies and ensure that masked roles are strictly limited in their ability to invoke cryptographic functions directly or indirectly. Regular audits of database permissions and monitoring for unusual patterns of hash generation can provide additional layers of defense against potential exploitation attempts until the update is fully deployed across all affected systems.