CVE-2026-105617 in PostgreSQL Anonymizer
Summary
by MITRE • 10/28/2026
PostgreSQL Anonymizer doesn't invalidate plans prepared after a rule was added or a role changed. Users using such plans can still see the unmasked data until the end of the session. 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 within PostgreSQL Anonymizer stems from an inconsistency between rule application logic and query plan caching mechanisms, specifically affecting scenarios where security policies are modified during an active database session. When a user executes a SQL statement that involves masked columns or rows defined by the anonymization rules, the database engine may generate a prepared execution plan to optimize subsequent executions of similar queries for performance efficiency. However, when an administrator adds new masking rules or modifies existing ones via role changes, this update does not trigger the invalidation of previously cached plans associated with other users or sessions that were established before the policy change. Consequently, any session holding these stale prepared plans continues to utilize execution paths that bypass the newly enforced anonymization logic, allowing access to data that should have been obscured according to the updated security posture.
This flaw represents a significant deviation from expected behavior in database security layers where dynamic rule updates must take immediate effect across all active connections or require explicit plan cache flushing mechanisms. The technical root cause lies in the lack of synchronization between the metadata changes triggered by role modifications and the internal state management of prepared statements within the PostgreSQL Anonymizer extension. Because the cached plans retain references to older versions of the masking functions or rules, they effectively ignore subsequent configuration updates until the session is terminated and restarted. This creates a window of exposure where sensitive information remains visible in plaintext form despite administrative efforts to enforce data privacy controls through role-based access adjustments.
The operational impact of this vulnerability is particularly severe for environments relying on PostgreSQL Anonymizer for compliance with regulations such as GDPR, HIPAA, or PCI-DSS, which mandate strict control over personally identifiable information and other sensitive datasets. Attackers who have established persistent connections to the database can exploit this timing gap to extract unmasked data even after security policies have been ostensibly tightened by administrators. This undermines the principle of least privilege and compromises the integrity of anonymization strategies that depend on real-time enforcement of masking rules based on user roles or group memberships. The risk is amplified in long-running application sessions where prepared statements are reused extensively, as these connections will remain vulnerable for their entire duration unless manually reset.
To mitigate this issue, organizations must ensure they upgrade to PostgreSQL Anonymizer version 3.3.0 or later, which addresses the plan invalidation logic to correctly refresh cached execution plans upon rule modifications. In environments where immediate upgrading is not feasible, administrators should implement operational procedures that require periodic session resets for high-privilege users after any significant change to anonymization policies. Additionally, monitoring tools should be configured to detect anomalies in data access patterns following policy updates, ensuring that no unexpected plaintext data retrieval occurs during the transition period. Regular audits of prepared statement caches and adherence to strict role management protocols further reduce the attack surface associated with this type of state inconsistency vulnerability.