PostgreSQL Anonymizer CVE-2026-9617

The attacker must hold an authenticated database account with CREATE TABLE privilege (PR:L). On PostgreSQL 14, or instances upgraded from PostgreSQL 14 or earlier, any user can create tables on the public schema by default, so this is readily met; on PostgreSQL 15 and later the CREATE permission on public is revoked by default, so exploitation requires a user who was explicitly granted CREATE TABLE. The attacker creates a table whose column identifier contains malicious SQL. Crucially, the code does not execute on its own - it fires only when a superuser invokes the k-anonymity function against the attacker-controlled object. Limiting factors: authenticated low-privilege access is required, a separate superuser action (calling k-anonymity) is the trigger and is outside the attacker's direct control, and PostgreSQL 15+ default schema hardening blocks table creation for unprivileged users.

Signals diverge sharply. The CVSS base score of 8.8 (High) reflects total technical impact - the SSVC framework also rates Technical Impact as 'total', consistent with code execution at superuser level (C:H/I:H/A:H). The CVSS vector is AV:N with PR:L, so this is an authenticated attack (a low-privileged database user), not an unauthenticated one. Against that severity, the exploitation-likelihood signals are weak: EPSS is 0.04% (12th percentile), SSVC Exploitation is 'none', SSVC Automatable is 'no', and the vulnerability is not in CISA KEV. The vuln.today decision label is 'this_week' rather than act_now/emergency. The key limiter is that exploitation is not self-contained: the attacker plants malicious code in a column identifier, but the payload only fires when a superuser separately invokes the k-anonymity function - an attacker-uncontrolled trigger that explains Automatable:no and the low EPSS. On PostgreSQL 15+, default revocation of CREATE on the public schema further narrows the attacker population to users explicitly granted CREATE TABLE. Net: a genuinely serious privilege-escalation bug worth patching this week, but not a widespread/automatable mass-exploitation threat - prioritize it on instances running PostgreSQL 14 or upgraded from 14-or-earlier where any non-trusted role can create tables.

A low-privileged database user who can create a table embeds SQL code inside a column identifier of a table they own. Later, when a superuser runs the extension's k-anonymity function against that object, the embedded code executes with superuser privileges, giving the attacker full control of the database. No public exploit was identified at time of analysis; the only reference is the vendor's GitLab issue tracker.