PostgreSQL Anonymizer CVE-2026-105618

Requires PostgreSQL Anonymizer prior to 3.3.0 deployed with masking rules applied to partitioned or inheritance tables (the configuration the project documentation explicitly recommends). The attacker must already hold an authenticated masked database role and must query the parent table rather than the child partitions - direct access to the partitions/inheritance child tables remains correctly masked. Limiting factors: exploitation is confined to this specific partition/inheritance masking setup and to users who already have a masked role; non-partitioned masking configurations and upgraded 3.3.0+ installations are unaffected.

This is a moderate-severity information-disclosure flaw, not an emergency. The input CVSS of 5.7 reflects confidentiality-only impact (C:H/I:N/A:N) and requires an authenticated low-privilege actor (PR:L), consistent with the vuln.today decision label of 'this_month' rather than act_now/emergency. No KEV listing, no EPSS score, and no confirmed proof-of-concept were provided - there is no public exploit identified at time of analysis, so this reads as a design/logic weakness rather than an actively exploited one. Signal conflict to flag: the supplied vector contains UI:R (user interaction required), but the described mechanism - a masked role simply querying the parent table - involves no obvious interaction, so UI:R appears questionable and should be verified with the vendor. The real priority is bounded: risk is only meaningful for deployments that follow the documented pattern of masking partitioned/inheritance tables, where anonymization can be silently bypassed; outside that configuration the issue does not apply.

An organization uses PostgreSQL Anonymizer dynamic masking and, per the project documentation, applies masking rules to partitioned or inheritance tables. A user holding a masked role - who should only ever see anonymized values - queries the parent table instead of the child partitions and receives the original unmasked sensitive data. No public exploit code is required; the bypass is triggered by ordinary SQL against the parent relation.