PostgreSQL Anonymizer EUVD-2026-112292

Requires (1) the PostgreSQL Anonymizer extension deployed with dynamic/role-based masking in use, (2) at least one masking rule defined using a sub-query, and (3) an attacker holding an authenticated database account mapped to a masked/anonymized role (PR:L). The flaw does not apply to default installs without sub-query-based masking rules. Limiting factors: the account must already be authenticated to PostgreSQL, impact is confined to disclosure of data that masking was meant to protect (no integrity or availability effect), and deployments running version 3.3.0 or later are not affected.

This is a moderate-severity, confidentiality-only issue rather than a top-priority emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, base 6.5) indicates a network-reachable, low-complexity flaw that requires an authenticated low-privilege database account (PR:L) and yields a high confidentiality impact with no integrity or availability effect - consistent with a data-masking bypass that leaks protected values. The vuln.today decision label is 'this_month', not 'act_now' or 'emergency', so urgency is elevated-but-routine. No CISA KEV listing and no EPSS score were provided, and the single reference is the vendor's GitLab issue tracker entry (a bug report, not working exploit code), so there is no public exploit identified at time of analysis and no evidence of active exploitation. The input 'Authentication Bypass' tag is misleading: CWE-862 (Missing Authorization) and the description describe a masking/authorization bypass where masked data is disclosed, not a bypass of login/authentication. Net: a real but bounded data-exposure risk, scoped to deployments that actually use masking rules containing sub-queries and to users who already hold a (masked) database role.

An analyst or application account that has been granted access only to masked/anonymized views of a PostgreSQL database runs a query that exercises a masking rule defined with a sub-query; because the sub-query result is not masked, the account receives the real underlying sensitive values instead of the anonymized ones. No public exploit code was identified; the only reference is the vendor's GitLab issue. Exploitation requires a valid low-privilege database session and a deployment whose masking rules use sub-queries.