PostgreSQL Anonymizer EUVD-2026-112294

Exploitation requires an authenticated PostgreSQL role that holds the TEMPORARY privilege on a deployment using the PostgreSQL Anonymizer extension for dynamic masking. The specific trigger is defining an anonymization function with a SQL-standard function body: PostgreSQL analyses (binds) such bodies at declaration time whereas Anonymizer only attempts its safety check at execution time, so the function bypasses Anonymizer's validation. Limiting factors: the attacker must already possess a database account with TEMPORARY privilege (not anonymous access), and only environments running Anonymizer versions prior to 3.3.0 are affected; the vendor fix in 3.3.0 and later resolves the mismatch.

This is a moderate-priority confidentiality flaw, not an emergency. The CVSS 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) reflects a network-reachable but authenticated issue: the attacker must already hold a PostgreSQL role with the TEMPORARY privilege, which bounds the population of potential exploiters to existing low-privileged database users rather than anonymous internet attackers. The single H is on confidentiality (bypass of the anonymization/masking protection, consistent with CWE-693 Protection Mechanism Failure), with no integrity or availability impact. Signals are consistent rather than conflicting: the vuln.today decision label is 'this_month' (routine patch-cycle urgency, not act_now/emergency), there is no CISA KEV listing, no EPSS score was supplied, and no public exploit is identified - so there is no evidence of active or widespread exploitation. The gap between a network attack vector and a prerequisite of an existing privileged account is the key nuance: realistic risk is driven by how many semi-trusted users have TEMPORARY privilege on databases that rely on Anonymizer for masking, not by raw CVSS alone.

A low-privileged but authenticated database user who holds the TEMPORARY privilege defines an anonymization function using a SQL-standard function body. Because PostgreSQL binds such bodies at declaration time while Anonymizer only validates them at execution time, the user's function escapes Anonymizer's safety checks and can be used to read data that should have remained masked. No public exploit is identified at time of analysis.