PostgreSQL Anonymizer EUVD-2026-72141

The target system must have the PostgreSQL Anonymizer extension installed and active, and the attacker must hold an authenticated database account that has been designated as a 'masked' user subject to anonymization rules. The attacker must additionally have the ability to define or influence database objects (operators, domain casts, or view subqueries) that the masking engine will evaluate - typically requiring CREATE privilege on at least one schema visible to the masking engine. The extension's masking mechanism must evaluate these objects in an elevated security context (security-definer or extension-owner context) for the privilege escalation to occur. Exploitation is constrained to deployments running PostgreSQL Anonymizer below version 3.1.4; environments that have never installed the extension are unaffected. There is no user-interaction requirement and no special network position is needed beyond the ability to connect to the PostgreSQL instance.

The CVSS 3.1 vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H scores 8.8, reflecting that any authenticated masked user on a reachable PostgreSQL instance can exploit this without special configuration beyond having the extension enabled. Real-world risk is elevated by several factors: the extension is explicitly deployed to enforce access controls for sensitive or regulated data (GDPR, HIPAA use cases), so exploitation directly undermines the security control the extension is meant to provide. The EPSS score is not provided in the input and cannot be assessed, but the attack complexity is low and the privilege requirement is only a basic database account. No CISA KEV listing exists and no public proof-of-concept is referenced, which slightly moderates immediate urgency. However, the scope metric in the provided vector (S:U) may understate impact: because the masked user's authorization scope is explicitly constrained by design and the exploit elevates them to the extension owner's security context, a scope change (S:C) is a reasonable interpretation, which would push the vector to a critical rating. The fix version is confirmed (3.1.4), making patching the unambiguous remediation priority. Organizations that cannot patch immediately face material risk since workarounds are limited.

An authenticated masked PostgreSQL user - for example, a database account with access to anonymized HR data - creates a custom operator or domain cast whose implementation contains malicious SQL such as a SECURITY DEFINER function call or a COPY FROM PROGRAM invocation. When the PostgreSQL Anonymizer masking engine evaluates the masked user's query and resolves masking rules, it invokes the malicious expression in an elevated security context, granting the attacker superuser-level database access and potential OS command execution. No public proof-of-concept is referenced in the available data.