CVE-2026-105619 in PostgreSQL Anonymizer
Summary
by MITRE • 10/28/2026
PostgreSQL Anonymizer doesn't mask data accessed thru a security_invoker view. The problem is resolved in PostgreSQL Anonymizer 3.3.0 and later versions.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/28/2026
The vulnerability identified within the PostgreSQL Anonymizer extension stems from an insufficient access control mechanism when interacting with views defined using the SECURITY INVOKER attribute. In database environments, particularly those handling sensitive personal or financial data, maintaining strict separation between raw source data and anonymized output is critical for compliance with regulations such as GDPR, HIPAA, and PCI-DSS. The PostgreSQL Anonymizer extension is designed to provide dynamic data masking capabilities, allowing applications to query databases while automatically obscuring specific columns based on predefined policies. However, a flaw in the implementation allows users who have been granted access through a security_invoker view to bypass these anonymization rules. This occurs because the context of execution for SECURITY INVOKER views reverts permissions to those of the calling user rather than maintaining the elevated privileges or strict policy enforcement intended by the extension's internal logic, thereby exposing underlying sensitive data that should remain masked.
From a technical perspective, this issue represents an authorization bypass where the application fails to enforce security policies consistently across different execution contexts. When a view is created with SECURITY INVOKER, PostgreSQL executes any functions called within that view under the privileges of the user invoking it. If the anonymization logic relies on session-level settings or role-based checks that are not properly isolated from this context switch, an attacker can exploit this discrepancy to retrieve unmasked data. This flaw aligns closely with CWE-269 Improper Privilege Management and CWE-862 Missing Authorization, as the system fails to ensure that only authorized operations on sensitive fields occur regardless of how they are invoked. Furthermore, in terms of offensive security frameworks, this vulnerability can be categorized under ATT&CK technique T1078 Valid Accounts if an attacker uses legitimate credentials but exploits the misconfiguration to access restricted data, or potentially T1539 Steal Web Session Cookie if session tokens were involved, though primarily it is a direct privilege escalation via configuration error.
The operational impact of this vulnerability is severe for organizations relying on PostgreSQL Anonymizer for compliance and privacy protection. Sensitive information such as personally identifiable information (PII), health records, or financial details could be exposed to unauthorized users who have access to the specific views that trigger the security_invoker behavior. This exposure not only violates data privacy laws but also erodes trust in the database infrastructure. Attackers with even basic read privileges on certain schema objects could potentially reconstruct sensitive profiles by querying these vulnerable endpoints. The risk is compounded if the anonymized view is exposed through an API or application layer that assumes all returned data is already sanitized, leading to a false sense of security among developers and administrators who may not audit every query path for such edge cases.
To mitigate this vulnerability, organizations must immediately upgrade PostgreSQL Anonymizer to version 3.3.0 or any later release where the patch has been applied. The fix ensures that anonymization policies are enforced consistently regardless of whether a view is defined with SECURITY DEFINER or SECURITY INVOKER attributes. In addition to upgrading, database administrators should review all existing views and functions within their PostgreSQL instances to identify other potential areas where security context might be improperly handled. It is advisable to implement the principle of least privilege by restricting direct access to base tables and ensuring that all data retrieval occurs through controlled interfaces or views that have been rigorously tested for bypass vulnerabilities. Regular audits using static analysis tools and penetration testing focused on authorization logic can help detect similar misconfigurations before they are exploited in production environments.