PostgreSQL Anonymizer EUVD-2026-112289

Requires an authenticated database session that prepared a query plan BEFORE a masking rule was added or the session's role was changed to a masked one; because PostgreSQL Anonymizer fails to invalidate those cached plans, the session keeps returning unmasked data until it ends. Limiting factors: the attacker/observer must already have a live database connection, must have a prepared statement that predates the masking configuration change, and the masking rule or role change must occur mid-session - fresh sessions and newly prepared plans are masked correctly, so default new connections are not affected. The only complete fix per the vendor is upgrading to PostgreSQL Anonymizer 3.3.0 or later.

This is a moderate, defense-in-depth data-exposure flaw rather than a high-priority external threat. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N, base 5.7) formally scores PR:N (unauthenticated), but the mechanism in the description contradicts a network-unauthenticated reading: the only party who benefits is an existing database session that holds a query plan prepared before a masking rule was added or a role was changed - i.e. an authenticated, already-connected database user whose own masked session keeps returning unmasked rows until it ends. The CVSS PR:N therefore overstates exposure; realistically this requires an authenticated session (verify auth model with vendor). Exploitation status: no KEV listing, no EPSS value supplied, and the sole reference is the Dalibo GitLab issue tracker (issue #695), which is not verified working exploit code - so this is 'no public exploit identified at time of analysis.' The vuln.today decision label is 'this_month,' consistent with a confidentiality-only, access-limited weakness that should be patched on a normal maintenance cycle rather than as an emergency. Net: a genuine but bounded information-disclosure bug affecting masked-data guarantees, not a widely weaponizable remote vulnerability.

In an environment using PostgreSQL Anonymizer to mask sensitive columns, a user establishes a session and prepares a query plan while masking does not yet apply to them. An administrator then adds a masking rule or changes the user's role to a masked one, but the previously prepared plan is never invalidated, so the user continues executing it and keeps reading the real, unmasked data until the session closes. No public exploit code exists; triggering it only requires the user to keep reusing the stale prepared statement within the same session.