PostgreSQL Anonymizer CVE-2026-105612

Exploitation requires an authenticated database session holding a masked role configured under PostgreSQL Anonymizer (the extension's read-only masking mechanism must be in use), plus the ability to submit SQL containing data-modifying CTEs. It does not apply to deployments that do not rely on masked roles for read-only enforcement. The limiting factors are strong: the attacker must already possess a provisioned masked-role account (PR:L), only integrity is affected (no data disclosure or availability loss), and upgrading to PostgreSQL Anonymizer 3.3.0 or later fully resolves the issue.

This is a genuinely low-severity, low-priority issue despite being an access-control bypass. The CVSS 3.1 base score is 3.5 (LOW) with vector AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:N, and the vuln.today Decision label is 'monitor' - the weakest urgency tier. The signals are internally consistent: there is no CISA KEV listing, no EPSS probability supplied, and no public exploit identified, so nothing points to active or imminent exploitation. The CWE-862 (Missing Authorization) classification matches the described behavior - a masked role using data-modifying CTEs to escape its read-only restriction - more than the 'Authentication Bypass' tag does; this is an authorization bypass by an already-authenticated low-privileged role, not an authentication bypass. Note one discrepancy worth flagging: the supplied vector sets UI:R (user interaction required), but the described mechanism is the masked role executing its own SQL, which would not normally require a separate victim's interaction - the UI:R basis is not explained in the available sources and should be verified with the vendor. Overall this is a low-real-risk, low-CVSS integrity issue confined to deployments relying on PostgreSQL Anonymizer's masked (read-only) roles.

An authenticated user assigned a masked (read-only) role in PostgreSQL Anonymizer issues a query containing a data-modifying common table expression (e.g., a WITH clause wrapping an INSERT/UPDATE/DELETE), which the extension fails to block, letting the role write data it should only be able to read. No public exploit code has been identified; the only reference is the vendor's GitLab issue tracker. Because the attacker is a provisioned masked role (PR:L), exploitation is limited to parties who already hold such an account.